合并前代码评审闸门

合并前代码评审闸门#

在代码提交、合并或发版前，对本次变更做逐项评审：拦截正确性、边界、并发、性能、安全、可读性六类缺陷并产出评审报告。纯指令技能：不带脚本、不联网、不写任何文件，产出直接在对话中给出。

触发时机#

• 用户要求「review / 评审 / 看看这段改动能不能合」；
• 提交 PR、合并分支、发版前的最后一道检查。

前置输入#

1. 先读 diff（变更范围），再读 diff 涉及文件的完整上下文——只看 diff 容易误判；
2. 明确本次变更的意图（修什么、为什么改）；意图不明时先确认意图本身，不猜。

六维检查清单（逐项过，不得跳项）#

1 正确性#

• 逻辑是否实现了声明的意图；反向用例是否成立；
• 返回值与错误分支是否都被处理；空值、零值、空集合是否安全；
• 状态机与流程的每个分支是否可达且正确。

2 边界条件#

• 输入为空、单元素、极大值、非法值时的行为；
• 数组与字符串越界、整数溢出、浮点精度；
• 时间边界：月末、闰年、时区、毫秒截断。

3 并发与状态#

• 共享状态是否有锁保护；锁粒度与加锁顺序是否可能死锁；
• 异步回调的时序假设是否成立；
• 重试、超时、部分失败之后的状态一致性。

4 性能#

• 循环内是否有可外提的 IO 或查询；N+1 查询；
• 数据量增长后的复杂度趋势——不是当前快，是十倍量级后是否还可用；
• 不必要的全量拷贝与重复计算。

5 安全#

• 外部输入是否校验；拼接 SQL、命令、路径是否可注入；
• 敏感信息（密钥、个人信息）是否落日志；
• 权限校验是否在入口处统一完成。

6 可读性#

• 命名是否表达意图；函数是否只做一件事；
• 注释解释「为什么」而非复述「做什么」；
• 与项目既有风格是否一致。

输出格式（评审报告）#

编号	位置（文件:行）	维度	严重级别	问题	建议修法

• 严重级别：P0 阻断合并（正确性/安全）；P1 应修（并发/性能）；P2 建议（可读性）。
• 没有发现问题的维度也要写明「已检查，未发现」——不写视为漏检。

结论三态#

• 通过：无 P0、无 P1；
• 有条件通过：有 P1，列出合并前必须修完的编号；
• 驳回：有 P0，说明理由与最小修复路径。

红线#

• 不以「能编译、能跑」替代评审——能跑不等于正确；
• 不用「整体没问题」这类总评替代逐项枚举；
• 发现 P0 必须同时给出可执行的修复建议，不能只报不修。