reviewing-code

代码审查

审查请求中的变更，而非整个代码库。除非请求修复，否则按只读方式处理。将此任务视为常规代码审查，并遵循安全基线；当安全是主要目标或验收标准时，应改用 auditing-code-security，而不是将此工作流扩展为全面的安全审计。

工作流

1. 根据请求以及仓库或 PR 上下文，确定确切的目标和比较基准。使用目标分支的合并基点；不要假定目标是 main。如果不涉及差异，请说明更广泛的文件审计范围。
2. 根据请求、问题/PR 上下文、测试、文档和周边代码推断预期行为。对重要假设加以标注。
3. 沿相关调用方、契约、状态、错误和下游使用方追踪变更后的行为。报告由变更引入、加重或变得可触发的问题；将直接相关的既存问题单独列出。
4. 在合理情况下检查以下方面：
   • 正确性、边界、状态转换、重试、并发、部分失败和清理
   • 重复工作在没有进展时会在哪里停止，以及最坏情况下的耗时、资源、成本和副作用
   • 接口、架构、迁移、作业、缓存、功能标志、权限和配置
   • 安全基线：受影响的资产和信任边界；身份验证/授权以及租户或对象所有权；从来源到接收点的验证和注入；机密、日志记录和敏感数据；依赖项和配置暴露
   • 重复工作、I/O、查询、阻塞、泄漏和预期规模
   • 针对变更行为和具体错误路径的测试；仅在可造成实际成本或风险时指出可维护性问题
5. 条件允许时运行针对性检查。检查通过有助于佐证正确性，但不能证明正确性。
6. 相关差异、直接受影响的契约/调用方以及针对性证据均已覆盖后即可停止。区分已确认的问题、推断出的风险和未经验证的方面。

请求修复时，先确认问题，再使用 hardening-code-paths 处理范围明确的边界情况或故障模式。不要提交推测性或纯偏好类评论。如果安全警报需要以威胁为重点进行可达性分析，应先使用 auditing-code-security。完成后重新审查所得差异和证据。

问题

先列出已确认的问题，并按严重程度排序：

• 严重： 严重的安全影响、数据丢失或大范围生产故障。
• 重大： 重要的正确性、可靠性、安全或可维护性风险，应阻止合并。
• 轻微： 确实存在、风险较低且值得修复的缺陷。

每个问题都应在可用时指出文件/行号、具体触发条件、影响和可执行的修复建议。除非请求指出，否则省略细枝末节。如果没有任何问题通过验证，应明确说明，并列出有实际意义的剩余风险或无法执行的检查。

仅在 PR/MR 或明确要求判断可合并性时给出合并结论：Approve、Approve with minor comments、Request changes 或 Needs more context。