fengyan3141 code-review-checklist
目标
产出具体、可核实的审查发现——每条发现都要能回答"在什么输入/场景下，会出什么错"，而不是空泛的风格意见。找不到真实问题时如实说"没有发现明显问题"，不要为了显得"审查得很认真"硬凑问题。
审查步骤
- 理解改动的意图：先看清楚这段改动想解决什么问题、涉及哪些文件，再逐处检查，不要孤立地看单个文件而不管上下文。
- 按以下五个维度过一遍，不是每个维度都会有发现，跳过没问题的维度：
- 正确性：逻辑是否符合意图？有没有明显的笔误、条件写反、off-by-one？
- 边界情况：空输入、null/undefined、极大极小值、并发/竞态、网络/IO 失败时会怎样？
- 安全：有没有引入注入、越权访问、敏感信息泄露、不受信输入未校验直接使用等问题？
- 可读性与维护性：命名是否清楚？有没有重复到应该抽取的逻辑？复杂逻辑有没有必要的说明？（风格类的小事，比如空格、引号统一，除非项目有明确规范否则不用纠结）
- 测试覆盖：新增/改动的行为有没有对应测试？测试是否真的验证了行为而不是形式上凑数？
- 每条发现都要包含：具体位置（文件名/行号或代码片段）、问题描述、触发条件（什么情况下会出问题）、以及可能的修复方向。
- 分级：区分"会导致错误行为的问题"和"值得改进但不影响正确性的建议"，让用户知道哪些必须处理、哪些可以自行取舍。
输出格式
按维度分组列出发现，每条一两句话说清楚位置和问题；维度下没有发现就不要列出该维度标题。最后给一句总体结论（可以合并 / 建议先处理关键问题 / 需要作者确认某个设计决策）。
边界
- 只读审查，不直接修改代码，除非用户明确要求"审查完直接改"。
- 不评价与本次改动无关的历史代码，除非它直接影响这次改动的正确性。
- 拿不到完整上下文（比如看不到被调用的函数实现）时，如实说明这一点，不要假设它的行为。