| name | code-review-checklist |
| description | 审查代码改动（review diff / PR）时使用——按固定清单过正确性、边界、错误处理和测试盲区，避免只看顺眼不顺眼。 |
代码审查清单
审查的第一原则：先读需求再读 diff。不知道这次改动想达成什么，就只能审出格式问题。
正确性（最高优先级）
- 改动是否真的解决了它声称要解决的问题？构造一个具体输入在脑中跑一遍。
- 有没有"顺手"改了不相关的行为？每一行改动都应该能追溯到本次目标。
- 并发/重入：这段代码被同时调用两次会怎样？
边界
- 空集合、空字符串、null/undefined、0、负数、超长输入——逐个问"这里会怎样"。
- 循环的第一次和最后一次迭代是否和中间行为一致？
- 时区、编码（UTF-8 BOM、CRLF）、路径分隔符这类"在我机器上没问题"的经典来源。
错误处理
- 失败路径是吞掉、抛出还是返回错误值？和周围代码的约定一致吗？
- 报错文案是否包含足够上下文（哪个文件、哪个参数、期望什么）让人照做就能修？
- 资源（文件句柄、子进程、定时器）在错误路径上是否也被释放？
测试盲区
- 新增分支有没有对应测试？没有的话，是"难测"还是"忘了"？
- 测试断言的是行为还是实现细节？断实现细节的测试会在无害重构时误报。
输出格式
按严重度分组给结论：必须改（正确性/安全）→ 建议改（可维护性）→ 可选（风格）。
每条指出具体行号和理由，不说"感觉不太好"这种无法执行的话。
