👤 个人开发者简化版：没有同事帮你 review，可这样做—— ① 用 PR 自审：开 PR 后隔几小时/隔天再自己逐行看一遍 diff，"陌生视角"最容易发现问题； ② 只对下方"必须审查"清单（认证/支付/核心逻辑/AI 生成代码）较真，其余快速过； ③ 把审查清单交给 AI 代跑一遍。跳过流程性的多人评审环节即可。
通过系统性的代码审查确保代码质量、安全性和可维护性，在问题进入生产前拦截，同时作为知识传递和标准统一的手段。
- 功能开发完成，合并到主分支前
- 修复 Bug 后提交前
- 重构完成后
- AI 生成的代码采纳前
- 涉及安全/支付/核心逻辑的变更
必须审查（不可跳过）：
- 认证/授权相关代码
- 数据库 schema 变更
- 支付/金额相关逻辑
- 删除/不可逆操作
- 公共 API 变更
- 安全相关（加密/验证/权限）
- 第三方服务集成
建议审查：
- 新功能实现
- 性能敏感代码
- 复杂业务逻辑
可自审通过：
- 文档更新
- 样式微调
- 依赖小版本升级
- 测试补充
按优先级排序：
1. 正确性（最高优先级）
- 逻辑是否正确？边界条件处理了吗？
- 是否满足需求/验收标准？
- 并发/竞态条件考虑了吗？
- 错误处理是否完善？
2. 安全性
- 用户输入是否验证和转义？
- 有无 SQL 注入/XSS/CSRF 风险？
- 权限检查是否到位？
- 敏感数据是否保护？
3. 性能
- 有无 N+1 查询？
- 有无不必要的循环/重复计算？
- 大数据量下是否会超时/OOM？
- 是否需要缓存/索引？
4. 可读性与可维护性
- 命名是否清晰有意义？
- 函数是否过长（> 50 行考虑拆分）？
- 是否有适当的注释（解释 why，不是 what）？
- 代码结构是否清晰？
5. 架构一致性
- 是否遵循项目架构模式？
- 是否违反分层原则？
- 是否引入不必要的耦合？
- 是否与现有代码风格一致？
每次提交前自己过一遍：
□ 代码能编译/运行通过
□ 所有测试通过
□ 无 console.log / debug 代码残留
□ 无硬编码的密钥/URL/配置
□ 错误处理完善（不是空 catch）
□ 新增代码有必要的注释
□ 变量/函数命名清晰
□ 无重复代码（DRY）
□ 边界条件已处理（null/空/极端值）
□ 涉及 UI 的已测试响应式
反馈分类标签：
[must]— 必须修改才能合并[suggest]— 建议改进，不阻塞[question]— 不理解，请解释[nit]— 极小的风格问题[praise]— 写得好的地方（别只挑毛病）
反馈格式：
[must] 这里没有处理 null 的情况，当 user 为 null 时会抛异常。
建议添加空值检查：if (!user) return next(new NotFoundError())
[suggest] 这个查询可以用 include 替代两次查询，减少 DB 往返。
[question] 为什么这里用 setTimeout 而不是 await？有什么特殊考虑吗？
反馈原则：
- 对事不对人（"这段代码有问题" 而非 "你写错了"）
- 给出具体建议，不只说"这不好"
- 说明原因（为什么这是个问题）
- 及时响应（24h 内完成审查）
1. 提交者：完成自审清单 → 提交 PR/MR
2. 提交者：写清楚 PR 描述（改了什么/为什么/如何测试）
3. 审查者：按维度逐项检查
4. 审查者：给出反馈（标注分类）
5. 提交者：处理反馈（修改或解释）
6. 审查者：确认修改 → Approve
7. 合并
- 自审清单已过一遍
- PR 描述清晰（what/why/how to test）
- 正确性已验证（逻辑/边界/错误处理）
- 安全性已检查（输入验证/权限/注入）
- 性能无明显问题
- 代码可读性良好
- 与项目架构/风格一致
- 测试覆盖充分
- 所有 [must] 反馈已处理
- 审查通过后才合并
| 输出物 | 格式 | 存放位置 |
|---|---|---|
| 审查记录 | PR/MR 评论 | GitHub/GitLab |
| 审查通过的代码 | 合并的分支 | main/dev |
| 误区 | 正确做法 |
|---|---|
| 只看格式不看逻辑 | 正确性和安全性优先于格式 |
| 审查 = 挑毛病 | 也指出写得好的地方 |
| 反馈模糊 "这不好" | 具体说明问题 + 给建议 + 说原因 |
| 大 PR 一次审完 | 大变更拆成小 PR（< 400 行） |
| 碍于面子不提问题 | 代码质量 > 面子 |
| 审查拖好几天 | 24h 内响应，小 PR 当天审完 |