pdlc-review

代码评审

对指定的服务或应用进行全面的代码评审。

PDLC 前置检查（必须执行，不可跳过）

1. 从用户输入中提取功能名称关键词
2. 检查实现代码是否存在：在 backend/ 和 frontend/ 下搜索与该功能相关的源代码文件（非测试文件）
3. 检查测试是否通过：找到对应的测试代码并运行，确认测试处于绿灯状态（全部通过）
4. 未找到实现代码 → 输出以下信息后立即停止，不继续执行：

   ⛔ PDLC 守卫：未找到与「<功能名>」相关的实现代码。
   评审必须基于已有的代码实现。请先运行：
   👉 /pdlc-implement <目标>
   

5. 测试未通过 → 输出以下信息后立即停止，不继续执行：

   ⛔ PDLC 守卫：「<功能名>」的测试未全部通过，无法进行评审。
   请先确保所有测试通过后再提交评审：
   👉 /pdlc-implement <目标>（修复失败的测试）
   

6. 检查通过 → 提取功能ID（从相关设计文档或 PRD 中），继续执行

评审流程

1. 阅读设计文档: 先阅读 docs/02_design/ 对应子目录下的相关设计文档
2. 阅读编码规范: 阅读 docs/00_standards/coding/ 目录了解编码规范（未命中 → 报告里提示 consider /pdlc-standard add coding/<topic>）
3. 检查代码实现: 对照设计文档逐一检查实现是否符合
4. 检查测试覆盖: 确认测试是否充分覆盖
5. 代码质量自动检查与修复（必须执行）：
   • 按 /pdlc-lint check 逻辑运行项目 lint 工具
   • 若存在可自动修复的问题，按 /pdlc-lint fix 逻辑自动修复
   • 记录修复前后的问题数变化

评审检查项（逐项检查，发现问题立即修复）

设计一致性（对照设计文档）

• 每个 API 接口的 URL、方法、参数是否与设计文档一致
• 数据库表结构、字段名、类型是否与 DB 设计一致
• 响应格式是否统一遵循 { code, message, data }

代码质量

• 命名是否规范（变量/函数/类遵循项目命名约定）
• 是否有重复代码可提取为公共方法
• 错误处理是否合理（不吞异常、不用空 catch、有意义的错误信息）
• 日志是否充分（关键操作有日志、不打印敏感信息）

安全检查

• SQL 注入：是否使用参数化查询/ORM，无字符串拼接 SQL
• XSS：用户输入是否转义后再输出
• 权限控制：接口是否有鉴权，敏感操作是否有权限校验
• 敏感数据：密码是否加密存储、Token 是否有过期机制、日志不含敏感字段

性能检查

• 数据库查询是否有 N+1 问题
• 列表接口是否有分页
• 是否有不必要的全表扫描（缺失索引）
• 大数据量操作是否有批处理

测试完备性

• 单元测试覆盖率是否达标（覆盖率达标线以项目配置为准：优先取 docs/00_standards/test-commands.yml 的 coverage 命令阈值参数（那才是强制点，退出码即判定），其次 quality-targets.yml；两者都没有时按 >= 80% 兜底。）
• 核心业务路径是否有完整的测试
• CHANGELOG 是否已更新

自动修复（评审中发现的问题，能修则修）

对以下类型的问题直接修复代码，不仅仅记录：

1. lint 问题：运行 lint fix 自动修复格式、规范问题
2. 命名不规范：自动重命名为符合项目约定的名称
3. 缺失错误处理：自动补充 try-catch / 错误码返回
4. 缺失日志：在关键操作处自动添加日志语句
5. SQL 注入风险：自动改写为参数化查询
6. XSS 风险：自动添加输出转义
7. 缺失分页：自动为列表接口补充分页逻辑
8. 缺失 CHANGELOG：自动追加变更条目