什么时候用请求修改
请求修改是评审里最重的动作：它会阻止合并，直到问题被解决并复核。适用的情形是有明确缺陷且必须修完才能合入——正确性错误、数据风险、安全漏洞、接口破坏、关键测试缺失。命名偏好、格式、可读性小建议不属于这一类，用普通评论或 nit 标注即可。
基本信息
| 适用平台 | GitHub 的 Request changes、GitLab MR 的请求修改 |
|---|---|
| 作用 | 默认阻止合并，直到问题解决并收到复核 |
| 使用前提 | 问题必须修完才能合入，而不是「我更希望这样」 |
| 解除方式 | 作者修复并逐条回复后，评审者复核并重新批准 |
什么时候用
- 逻辑错误、计算错误或明显的边界遗漏：合入后会产生错误结果。
- 数据风险：迁移不可逆、可能丢数据、并发下会写坏状态。
- 安全漏洞：越权、注入、敏感信息落进日志或响应。
- 接口破坏：调用方会直接失败或行为静默改变。
- 关键测试缺失：改动改变了行为却没有能失败的测试保护。
什么时候不用
- 命名与格式偏好：用 nit 标注，说明不阻塞合并。
- 可读性小建议：给出方向让作者判断，不强制立刻改。
- 方案层分歧：先讨论方向，用请求修改表达偏好会卡住流程。
- 可以后续跟进的重构：记为后续任务，避免改动越滚越大。
意见分层与处理
| 层级 | 处理方式 |
|---|---|
| 阻塞项 | 逐条列出，说明后果与验收标准 |
| 建议项 | 标注为非阻塞，允许作者判断 |
| 后续项 | 写进任务或描述，不在本次范围 |
| 待确认项 | 先提问澄清，确认后再定性 |
请求修改的写法
请求修改的写法
# 差：只给结论
这里有问题，改一下。
# 好：问题 + 后果 + 验收标准
并发场景下这段读改写没有加锁，两个请求同时到达可能丢失一次更新。
建议用单条原子更新语句，或把读取与写入放进同一个事务；
修复后请补一个并发用例。把意见分层（阻塞与非阻塞）能显著减少来回次数：作者知道先改什么，也知道哪些可以商量。
发出请求修改后要记得回来复核：作者已修复而评审者未重新批准，改动会一直卡在队列里。