代码审查

一套有步骤、可复现的代码审查方法，产出按严重程度分级、可执行的评审结论。

何时使用

• 审查他人提交的 PR / diff。
• 提交前对自己的改动做一轮自查。
• 在一份陌生的代码里快速建立理解并挑出风险。

审查流程

1. 先建立上下文（不要跳进 diff）

• 读 PR 描述 / issue：它想解决什么问题？
• 看改动范围：改了哪些文件、涉及哪些模块。
• 明确变更的“预期行为”，后续所有判断都围绕它。

2. 按维度逐项检查

正确性 (Correctness)

• 边界条件：空输入、极端值、并发、时间/时区。
• 空指针/未定义行为/资源泄漏（文件句柄、连接、锁）。
• 异常路径是否有清晰处理，能否部分成功留下脏状态。
• 数值/单位/换算是否一致（工程场景尤其重要）。

安全 (Security)

• 输入是否经过校验和净化（注入、路径穿越、XSS）。
• 是否处理敏感数据（密钥、凭据、日志脱敏）。
• 权限/授权是否在服务端强制，而非仅前端。

性能 (Performance)

• 是否存在明显低效：N+1 查询、O(n²) 循环、阻塞调用进异步路径。
• 是否成倍放大 I/O、重复计算、未复用对象。

清晰与可维护性 (Clarity & Maintainability)

• 命名是否表意；函数是否单一职责。
• 是否有不必要的复杂度 / 魔法数字 / 重复代码。
• 是否有易于出错的写法；注释是否解释“为什么”而非“做了什么”。

测试 (Testing)

• 关键路径、分支、失败路径是否有测试覆盖。
• 测试是否断言了正确行为而非实现细节。

3. 结构化输出评审意见

按严重程度分级，并给出修改建议而非命令：

每条意见格式：[级别] 位置: 问题说明 → 建议（可选）

4. 沟通准则

• 对事不对人，聚焦代码而非作者。
• 用提问代替否定：“这样做会不会有 X 风险？”
• 区分“必须改”与“可自行判断”。
• 提供具体、可执行的修复方向。

输出模板

## 结论
- 是否可合并：是 / 否（需修复 N 个阻断项）

## 阻断 (Block)
- 文件:行 —— 问题（必须改）

## 重要 (Major)
- 文件:行 —— 问题 → 建议

## 建议 (Minor) / 疑问 (Question)
- ...