先核对补丁解决的是否是原问题

审查前写下复现步骤与预期行为，阅读完整 diff 和新增文件。把每个修改对应到需求或已确认的必要修复；无法解释的重构、依赖升级与格式大改应单独处理，避免让审阅范围失控。测试看似增加很多，也可能只重复实现而没有覆盖原问题。

检查调用链中的输入、权限、错误和副作用。尤其关注助手是否用默认值掩盖无效状态、放宽访问条件或吞掉失败。对外错误必须遵循项目既有脱敏路径，内部配置与来源信息不能被顺手返回给终端用户。

挑选能推翻实现的验证

先运行可以复现原问题的检查，再加入与风险对应的反例：空输入、权限不足、取消、重复事件或部分失败。测试应检查可观察行为，而不是只断言内部函数被调用。涉及网络或持久化副作用时，优先用受控替身验证，不能让审阅过程顺带执行真实付款或生产写入。

检查补丁的依赖变更是否同时更新锁文件，配置示例是否只有占位符，以及新增日志是否会泄露用户输入。前端改动需要结合类型检查、构建和适用的真实界面验收；后端改动则按受影响逻辑选择测试，不能用一次构建代替所有行为验证。

带着限制形成审阅结论

为每个发现写明触发条件、影响和最小修复方向。不要因为代码出自助手就默认错误，也不要因为输出解释流畅就降低证据标准。修复后只重跑受影响及必要回归检查，并确认新的改动没有混入并行任务文件。

提交前检查敏感信息、最终 diff 与工作区状态。报告哪些验证实际运行、哪些由于环境受限未能运行，以及剩余风险。通过测试说明所覆盖的条件满足要求，不能证明所有输入都安全；保留可回退提交与明确的上线权限边界。

参考资料

由 NexoToken 维护的自营资料站。平台介绍包含运营方利益关系，不构成独立第三方认证。