| name | code-review |
| description | Comprehensive code review guidance — process, checklist, feedback conventions. Use when the user asks about code review flow, review criteria, best practices, or how to give/receive review feedback. |
| keywords | ["code review","代码审查","PR","pull request","review","审查"] |
代码审查指南
适用场景
当用户咨询代码审查流程、审查标准、最佳实践等问题时，参考本指南进行回答。
一、审查流程
1.1 提交前自查
开发者在提交 Code Review 前应完成以下自查：
- 代码能正常编译和运行
- 所有单元测试通过
- 没有遗留的 TODO 或调试代码
- 代码风格符合团队规范
- 提交信息清晰描述了变更内容
1.2 审查步骤
- 了解背景: 阅读 PR 描述和关联的需求/Bug 单
- 整体浏览: 先看文件变更列表，理解改动范围
- 逐文件审查: 从核心逻辑文件开始，关注重点代码
- 运行验证: 对关键改动 checkout 代码本地运行验证
- 给出反馈: 区分"必须修改"和"建议优化"
二、审查重点
2.1 功能正确性
- 逻辑是否正确，边界条件是否处理
- 异常情况是否妥善处理（空值、超时、并发）
- 数据校验是否充分
2.2 代码质量
| 维度 | 检查项 |
|---|
| 可读性 | 命名是否清晰，注释是否必要且准确 |
| 简洁性 | 是否有重复代码可提取，逻辑是否过于复杂 |
| 可维护性 | 是否易于扩展，依赖是否合理 |
| 一致性 | 是否遵循项目现有的代码风格和模式 |
2.3 安全性
- 用户输入是否做了校验和转义
- SQL 是否使用参数化查询（防注入）
- 敏感数据是否加密存储
- API 接口是否有鉴权
2.4 性能
- 是否有 N+1 查询问题
- 大数据量操作是否有分页
- 是否有不必要的重复计算
- 数据库查询是否使用了索引
三、反馈规范
3.1 反馈分级
- [MUST]: 必须修改，存在 Bug 或安全隐患
- [SHOULD]: 建议修改，影响代码质量
- [NICE]: 可选优化，锦上添花
3.2 反馈示例
好的反馈：
[MUST] 这里没有处理 user 为 null 的情况，当用户未登录时会抛出 NullPointerException。建议加一个空值检查。
不好的反馈：
这段代码有问题。
四、审查效率建议
- 单次审查不超过 400 行代码
- 审查时间不超过 60 分钟
- 使用工具辅助（静态分析、CI 检查）
- 重要改动应有两人以上审查
