增量质检报告 — dzs/dzs-api

• 项目：dzs/dzs-api（Rust / Salvo + SeaORM）
• 分支：v1.0.73
• 对比区间：59e1a67dda0452090436b7f492b0014705c57ff3 → 376ea8c4bed689ed6a1d16563e0fc555e039e63b
• 变更主题：新增 POST /api/v1/auth/set-password（首次设置密码），认证路由 7 → 8
• 结论速览：变更面小、边界清晰、门禁齐全，未发现真实缺陷；质检 diff 中的「修复 9 条」全部是行号平移造成的假象，13 条「新增」中仅 2 条与本次生产代码相关（均为指标型/误报）。

---

一、变更范围（9 个文件）

---

二、变更逻辑核验（逐点确认，无缺陷）

1. 幂等 / 并发安全：落库用条件更新 UPDATE ... SET password_hash=? WHERE id=? AND password_hash IS NULL；rows_affected == 0 → 2001。并发双写只可能一个成功，另一请求得到 0 行 → 2001，不会覆盖。
2. 快路径一致性：先用中间件注入的实体 cached.password_hash.is_some() 直接拒绝（P2-13 复用），DB 条件更新作为最终权威兜底。二者结论一致，无 TOCTOU 漏洞。
3. 鉴权门禁自洽（三重校验）：
   • perf_registry::security_matches_auth_protection 要求受保护操作声明 security——handler 已声明；
   • perf_registry::auth_hoop_count_matches_registry 校验 router 中 auth_required 挂载次数——已同步为 9；
   • openapi_guard::body_reading_ops_declare_request_body 要求读 body 的写接口声明 requestBody——已声明 SetPasswordReq。
4. 与改密接口互斥清晰：PUT /user/password（user_service::change_password）对 password_hash IS NULL 的用户返回 1001「当前未设置密码」；本接口正是补齐该类用户（短信/微信/一键登录自动注册）的初始化入口，语义不重叠。
5. 客户端可发现性：ProfileResp.has_password 已暴露，客户端据此决定展示「设置密码 / 修改密码」，README「仅 has_password=false 可用」口径成立。
6. 错误码契约：2001 → AppError::business → HTTP 400；未登录 → 1002 → HTTP 401，与 e2e 断言（400/2001、401/1002）及 README 一致。

结论：新端点实现正确，未发现逻辑、安全或并发缺陷。

---

三、修复的问题（工具原数据：9 条）

⚠️ 经核对，以下 9 条全部是「行号平移」假象，并非本次真正修复的缺陷——同一规则在 head 中以新行号重新出现在「新增」列表（见第四节逐条对应）。本次改动未修复任何历史缺陷（也无历史缺陷需要修复）。

平移量核验：set_password 方法体（含 doc）净插入 38 行，故 auth_service.rs 的历史问题行号统一 +38；e2e 新用例净插入 36 行，故 456 → 492 精确对应（同一行 public-prices?start_date=...&end_date=... 超 120 字符）。

---

四、新增的问题（工具原数据：13 条）— 分类与判定

归类小结：

• 真正由本次变更引入（生产代码）：仅 #1、#2；其中 #2 为误报，#1 为可豁免的耦合指标。
• 由本次变更引入（测试代码）：#10、#11（新单测）+ #12（误报）。
• 其余 7 条（#3–#9、#13）= 历史问题因行号平移被重复计数，非新增。
• 无任何新增缺陷（Bug/安全/逻辑）。

---

五、风险与建议

残余风险（设计取舍，非缺陷，建议产品/安全侧确认）

1. 本接口不要求短信验证码或原密码二次校验，仅凭有效 access token 即可「首次设密」。若 access token 泄漏，攻击者可据以设置密码长期占用账号。App 侧如需更强保护，可增加「近期登录 / 短信二次校验」约束。
2. 设密成功后不轮换、不拉黑 token（按 PRD「保留当前登录态」）。与该语义一致的现有接口（改密走 PUT /user/password）亦如此，口径统一。
3. 无密码强度规则（仅 ≥8 位），有意与 PUT /user/password 保持一致，避免两端口径分叉——可接受。

文档小瑕疵（nitpick，不影响运行）

• src/openapi_guard.rs 顶部注释仍写「全量 OpenAPI 文档（54 个操作）」，现已 56（tests/e2e/swagger-discoverability.spec.js 明确 53 路径 / 56 操作）。
• src/perf_registry.rs 中 AUTH_PROTECTED_PREFIXES 注释「8 个 GET 返回 1002」未随新增 POST 前缀更新（语义不冲突，仅未同步）。
• src/services/auth_service.rs 模块头注释「认证服务（G-3）：发码 / 注册 / 密码登录 / 短信登录 / 刷新 / 登出」未补 set_password。

建议动作

• 采纳项：同步上述 3 处文档注释（低优先）。
• 改动项：#1/#2 耦合与注释指标建议在基线中标记豁免，避免后续 diff 噪声；#3–#9、#13 属历史基线，无需在本 Release 处理。

---

六、总体评价

本次为单一特性增量（首次设置密码），实现遵循项目既有约定（Depot 复用、统一错误码、门禁驱动）。功能正确、并发安全、鉴权与文档门禁全部同步，未发现真实缺陷。质检 diff 的数值波动主要来自行号平移，不代表质量退化，可直接合入。