code-review-checklistlisted

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