---
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 前应完成以下自查：

1. 代码能正常编译和运行
2. 所有单元测试通过
3. 没有遗留的 TODO 或调试代码
4. 代码风格符合团队规范
5. 提交信息清晰描述了变更内容

### 1.2 审查步骤

1. **了解背景**: 阅读 PR 描述和关联的需求/Bug 单
2. **整体浏览**: 先看文件变更列表，理解改动范围
3. **逐文件审查**: 从核心逻辑文件开始，关注重点代码
4. **运行验证**: 对关键改动 checkout 代码本地运行验证
5. **给出反馈**: 区分"必须修改"和"建议优化"

## 二、审查重点

### 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 检查）
- 重要改动应有两人以上审查