review 提示词

对当前代码库或本次变更执行一次严格、全面、面向生产环境的 Code Review。

先阅读相关实现、调用链、类型、配置、测试和项目约定。不要只看 diff 表面，不要为了凑数量制造问题。

重点审查：

1. **正确性**

   * 功能是否符合需求
   * 边界条件、异常路径、状态转换是否正确
   * 是否存在数据不一致、竞态、重复执行、异步遗漏、资源泄漏
   * 错误是否被吞掉、错误转换或错误兜底

2. **代码结构**

   * 模块、类、函数职责是否清晰
   * 是否存在大文件、大函数、深层嵌套、跨层调用、循环依赖
   * 业务逻辑、基础设施、数据访问、接口层是否合理分离
   * 数据流、控制流和资源生命周期是否清晰

3. **架构与设计**

   * 是否符合项目现有架构
   * 依赖方向是否合理
   * 是否存在高层依赖低层细节、隐式耦合、全局状态、多状态源
   * 设计模式是否真正必要且使用正确
   * 是否存在错误抽象、抽象不足或抽象泄漏

4. **扩展性**

   * 新增同类功能是否需要修改大量无关代码
   * 可变部分与稳定部分是否分离
   * 是否写死具体平台、协议、模型、数据源或实现
   * 是否具备合理扩展能力，但避免为假设中的未来需求提前建设框架

5. **可维护性**

   * 命名、类型、接口和数据结构是否准确
   * 是否存在隐式副作用、魔法值、复杂布尔参数、重复转换
   * 是否容易理解、测试、修改和定位问题
   * 注释是否准确，是否存在过期或误导性注释

6. **可靠性与安全**

   * 超时、取消、重试、事务、回滚、幂等是否正确
   * 文件、连接、流、定时器、监听器等资源是否正确释放
   * 输入校验、鉴权、授权、敏感信息、注入、路径、反序列化是否安全

7. **性能**

   * 是否存在 N+1、循环 I/O、重复计算、重复序列化、无界缓存
   * 是否存在阻塞异步流程或明显不合理的复杂度
   * 不要提出无证据的微优化

8. **测试**

   * 核心路径、边界、异常和回归场景是否覆盖
   * 测试是否验证真实行为，而不是实现细节
   * 必须指出具体缺失的测试场景，不要只写"增加测试"

9. **重复、兼容与废弃**

   * 禁止无依据保留旧兼容逻辑
   * 禁止重复实现已有能力
   * 禁止过度设计、过度兜底和重复抽象
   * 已确认无调用、废弃、不可达或被替代的文件、函数、类型、配置、依赖、资源和测试，应直接删除
   * 删除时同步清理调用方、类型、配置、测试、文档和依赖
   * 不要仅添加 deprecated、TODO、空壳包装或新的兼容层

审查原则：

* 优先报告真实缺陷、结构性问题和高价值风险
* 不要把个人风格偏好当作问题
* 不要建议无需求支撑的大规模重构
* 不要默认旧行为必须兼容
* 不要通过新增抽象或兜底掩盖根因
* 每个问题必须有具体代码依据
* 每个问题必须说明触发条件、实际影响和最小修改方案
* 无法确认的问题标记为"需要确认"
* 没有实质性问题时明确说明，不要强行输出问题

严重级别：

* `P0`：安全漏洞、数据损坏、系统不可用
* `P1`：核心功能错误、严重状态不一致、资源泄漏
* `P2`：特定条件下的错误、明显设计缺陷、较高回归风险
* `P3`：局部结构、维护性、测试或性能问题
* `Suggestion`：非阻塞但有明确收益

输出格式：

# Review Summary

* 是否建议合并
* 整体风险
* 最重要的 3 个问题
* 结构与架构评价
* 扩展性评价
* 测试评价
* 是否存在应删除的废弃或重复内容

# Findings

每个问题使用：

## [P1] 标题

* 文件与位置：
* 所属维度：
* 问题：
* 触发条件：
* 实际影响：
* 根本原因：
* 最小修改方案：
* 需要补充的测试：
* 是否阻塞合并：

# Delete List

仅列出能够确认应删除的内容，并给出删除依据。

# Final Verdict

明确说明：

* 是否可合并
* 合并前必须修复的问题
* 可后续处理的问题
* 推荐的最小修改路径