huqy123 发布候选审查
基本原则
- 先明确目标是提测、合并还是发布，并记录候选版本、目标引用和实际审查范围。
- 分开说明需求“应该怎样”、代码“实际怎样”和页面/数据/消息/日志“运行后怎样”。
- 编译通过只证明代码可编译，不能证明入口可达、数据不丢、批量范围正确或下游可用。
- 有阻断缺陷或关键证据缺失时，不给出放行结论；未授权不修改、提交、合并或推送。
正向核对
沿“真实入口 → 输入与契约 → 权限和校验 → 处理 → 状态/副作用 → 可观察结果 → 下游”逐段核对：
- 输入、标识、空值和版本是否完整。
- 复制、覆盖、删除、批量和失败重试是否保持范围和状态一致。
- DTO、实体、JSON、数据库、消息和快照之间是否丢字段。
- 保存后重新查询、重开和下游消费是否读取同一份最新数据。
- 适用时检查数据库迁移、兼容、并发幂等、缓存、监控、回滚和容量。
必测场景
按改动选择：单条/批量、无数据/已有数据、首次/再次打开、成功/失败重试、新旧数据、复制/修改/删除、前端提交/绕过前端的非法请求。每个场景写明触发者、判断条件、状态变化、观察方式和下游结果。
反向复核与结论
从最终页面或下游结果反查数据来源，重点找不可达代码、批量范围过大、复制误删和只在单层存在的字段。最后说明候选范围、检查命令和结果，明确哪些已验证、哪些只能到测试环境验证、哪些仍阻断。改完代码后重新读取最终 diff 并重跑受影响检查。