---
name: code-review-checklist
description: 审查代码改动（review diff / PR）时使用——按固定清单过正确性、边界、错误处理和测试盲区，避免只看顺眼不顺眼。
---

# 代码审查清单

审查的第一原则：**先读需求再读 diff**。不知道这次改动想达成什么，就只能审出格式问题。

## 正确性（最高优先级）

- 改动是否真的解决了它声称要解决的问题？构造一个具体输入在脑中跑一遍。
- 有没有"顺手"改了不相关的行为？每一行改动都应该能追溯到本次目标。
- 并发/重入：这段代码被同时调用两次会怎样？

## 边界

- 空集合、空字符串、null/undefined、0、负数、超长输入——逐个问"这里会怎样"。
- 循环的第一次和最后一次迭代是否和中间行为一致？
- 时区、编码（UTF-8 BOM、CRLF）、路径分隔符这类"在我机器上没问题"的经典来源。

## 错误处理

- 失败路径是吞掉、抛出还是返回错误值？和周围代码的约定一致吗？
- 报错文案是否包含足够上下文（哪个文件、哪个参数、期望什么）让人照做就能修？
- 资源（文件句柄、子进程、定时器）在错误路径上是否也被释放？

## 测试盲区

- 新增分支有没有对应测试？没有的话，是"难测"还是"忘了"？
- 测试断言的是行为还是实现细节？断实现细节的测试会在无害重构时误报。

## 输出格式

按严重度分组给结论：**必须改**（正确性/安全）→ **建议改**（可维护性）→ **可选**（风格）。
每条指出具体行号和理由，不说"感觉不太好"这种无法执行的话。