代码审查清单

审查容易漏项、标准不一致

拉取请求一多，审查者往往只盯「能不能跑」，边界条件、鉴权、N+1、测试是否真有意义很容易被跳过；团队若没有统一维度，新人与老手的审查深度也会差一截。

技能如何组织一次审查

本技能把审查拆成可执行的六步，并在每步给出可对照的问题与勾选项：

1. 理解背景 — 变更解决什么问题、改了哪些文件、测试策略是什么。
2. 功能 — 是否满足需求、边界与错误处理、有无逻辑漏洞。
3. 代码质量 — 可读性、命名、结构、单一职责、是否过度复杂。
4. 安全性 — 输入校验、敏感数据、注入与身份认证/授权、依赖风险。
5. 性能 — 多余循环、数据库与缓存、内存与 N+1。
6. 测试 — 新代码是否有测试、边界与失败路径、覆盖率是否够用。

文末附带完整勾选清单（含文档、Git 提交与分支卫生），以及「应该 / 不应该」的实践对照、常见陷阱（边界遗漏、安全、测试不足、可读性差）与评论模板（请求修改、提问、表扬），便于在 PR 里写出具体、可操作的反馈。

适用边界

清单偏通用工程实践，不替代你们仓库自带的 linter、CI 或安全扫描；风格与架构约定仍需按项目文档裁剪。与「准备被审代码」「接收审查反馈」类技能搭配时，分工更清晰：本技能侧重审查者侧的系统性不漏项。