中文代码审查

---
name: code-review-zh
description: 当用户需要审查代码改动、评估 Pull Request 或排查潜在缺陷时使用。包含按优先级分层的检查路径、需要重点怀疑的模式，以及审查意见的表述方式。
---

# 中文代码审查

## 审查顺序

按这个优先级走，不要一上手就挑格式问题：

### 第一层：正确性（必须发现）

- **边界条件**：空数组、空字符串、0、null/undefined、单元素、超长输入
- **异步与并发**：竞态、未处理的 rejection、事务边界、重复提交
- **错误处理**：catch 里是否吞掉了原始错误；错误状态码是否被覆盖成统一的 500
- **数据一致性**：多步写入是否有中间失败的可能，失败后是否留下脏数据
- **认证与授权**：写操作是否都校验了身份；能否越权访问他人数据

### 第二层：可靠性

- 外部依赖失败时的行为（超时、重试、降级）
- 资源释放（连接、文件句柄、定时器、事件监听）
- 日志是否足够定位问题——尤其 catch 块里是否记录了原始错误

### 第三层：可维护性

- 命名是否表达意图
- 是否与周边代码风格一致（缩进、注释密度、命名习惯）
- 是否有重复逻辑该抽取，或过早抽象该内联

### 第四层：风格

交给 linter。人工审查花在这里是浪费。

## 高频怀疑模式

这些模式一出现就值得停下来细看：

| 模式 | 为什么可疑 |
| --- | --- |
| `catch (e) {}` 或 catch 里不记日志 | 真实原因被永久丢弃，线上无法排查 |
| catch 里统一抛 500 | 会把 401/403/404 覆盖成 500，客户端无法区分 |
| 变量声明在使用之后 | 可能触发暂时性死区错误 |
| 直接用请求参数拼查询 | 注入风险 |
| 密码、密钥有硬编码兜底值 | 配置缺失时静默使用弱默认值 |
| 权限判断在客户端 | 绕过成本极低 |
| 循环里发请求或查库 | N+1 问题 |
| 新增字段但没更新索引 | 查询退化为全表扫描 |
| 时间用本地时区 | 跨时区行为不一致 |
| 浮点数做金额计算 | 精度丢失 |

## 意见怎么写

**分级标注**，让作者知道哪些必须改：

- `[阻塞]` 会导致错误行为，必须改
- `[建议]` 可以更好，作者可自行判断
- `[疑问]` 我没看懂，想确认意图

**给出具体场景而不是判断。** 不写"这里有 bug"，写"当 items 为空数组时，第 12 行的 items[0] 会是 undefined，第 15 行访问 .id 会抛错"。可复现的场景无法争辩，抽象的判断会引起防御。

**不要要求对方证明自己没错。** 如果不确定，用 `[疑问]` 而不是断言。

## 审查者自己的自查

- 我是否读完了完整的改动，而不是只看了 diff 片段？
- 我提的每条"阻塞"，能否说出一个具体的失败输入？
- 我是否在用个人偏好冒充工程标准？
- 如果这份代码由我维护半年，哪一处会让我最难受？