代码审查清单

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

正确性（最高优先级）

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

边界

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

错误处理

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

测试盲区

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

输出格式

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