# 基本原则
* 改动范围是否 仅限于当前问题的最小集合（无顺手重构/未来预留）？
* 对外接口（输入/输出/错误）是否保持兼容；如需变更，是否提供迁移说明与灰度方案？
* 是否优先复用已有模块/方法，避免重复造轮子？
* 命名是否清晰，函数是否单一职责，是否具备必要注释/契约描述？
* 代码中是否存在魔法数或隐式副作用？

# 日志与错误处理
* 关键路径（入口/外部调用/异常）是否有 结构化日志？
* 日志内容是否清晰、有助于排查？
* 日志是否避免泄露敏感信息？
* 是否存在被吞掉的异常；异常输出是否包含上下文信息？

# 配置与依赖
* 新增依赖是否在 白名单/依赖清单中？
* 配置是否通过环境变量或集中配置管理？
* 仓库中是否存在密钥或默认秘钥？

# 异步与性能
* 外部 I/O 是否具备 超时 + 有限重试（指数退避）？
* 是否存在阻塞执行路径的 CPU 密集逻辑（如有，应转移至后台任务/队列）？

# 安全基线
* 外部输入是否全部经过校验？
* 输出是否经过安全编码？
* 文件 / URL / 命令操作是否经过白名单或显式校验？

# 一票否决项
* 是否引入了无必要的 自研框架/抽象层？
* 是否为潜在场景设计了复杂扩展点？
* 是否存在大面积重构，但缺乏明确收益与回滚方案？

# 审查结论
* 改动是否为 渐进式最小集合，无预支未来需求？ ✅/❌

# 特殊说明
* 若问题过多或难以维护：是否需要重构？（仅限指定文件）
* 是否检查了周边依赖，而未越界改动其他文件？

# 红线提醒
* 严禁自作主张的过度设计
* 严禁提交敏感信息
* 严禁破坏既有契约
