代码评审

五轴代码评审：正确性、可读性、架构、安全、性能。适用于合并前自查、评审 AI 生成的代码、审查客户项目交付物。

代码评审（五轴法）

结论先行

评审要回答一个问题：这个改动是让代码库更健康，还是更糟？ 变好了就批准，不必完美。

不要因为"我会换个写法"而阻挡；要因为"这里会出错/看不懂/有风险"而阻挡。

关键事实

| 项 | 说明 |

| --- | --- |

| 评审顺序 | 正确性 → 安全 → 架构 → 可读性 → 性能 |

| 改动规模 | 单次评审建议 ≤ 400 行；超出先拆 |

| 必看前提 | 测试是否通过、是否有对应的回归测试 |

| 输出结论 | 批准 / 需修改 / 阻断，三选一，不含糊 |

步骤

1. 先跑，再看

- 有测试就跑测试；没有就手动跑一遍关键路径；

- 记录结论：通过了什么，没验证什么。

2. 看规模与范围

```powershell

git -C <repo> diff --stat HEAD~1

git -C <repo> diff HEAD~1 -- <关键文件>

```

超过 400 行且混了多个主题 → 要求拆分，不逐行读。

3. 按五轴过一遍

| 轴 | 逐条问 |

| --- | --- |

| 正确性 | 符合需求吗？边界（空/越界/重复）处理了吗？错误路径有分支吗？ |

| 安全 | 输入校验了吗？密钥有没有进代码/日志/仓库？权限检查了吗？ |

| 架构 | 跟着现有模式走吗？依赖方向对吗？有没有把特例塞进通用模块？ |

| 可读性 | 命名说人话吗？能不能少一半行数？有没有"聪明"技巧该拆？ |

| 性能 | 有没有循环里查数据库/发请求？有没有无上限的列表加载？ |

4. 给证据，不给感觉

- 每条问题写：文件:行号 + 现象 + 后果 + 建议；

- 区分「必须改」与「可以改」，别把偏好混进去。

5. 下结论

- 批准：可以合并，遗留项列为后续；

- 需修改：列出阻断项，改完再评；

- 阻断：安全问题或正确性错误，说明触发条件。

输出模板


结论：需修改（2 项阻断 / 3 项建议）
阻断：
1. src/auth.mjs:42 未校验 token 过期，重放可越权
2. scripts/release.mjs:18 把密钥写进日志
建议：
- src/main.js:120 嵌套过深，可提前 return
未验证：Windows 下的路径处理（无测试覆盖）

坑

验收清单

别做的事