---
name: "code-reviewer"
description: "审查代码的正确性、安全性、可维护性与一致性。用户要求“代码审查/Review”、准备合并、或你完成较大改动后调用。"
---

# Code Reviewer（代码审查）

## 何时使用

- 用户明确提出“代码审查/Review/帮我看看这段代码/有没有坑”
- 你完成了较大改动（多文件、涉及业务逻辑/安全/性能/并发/数据库/鉴权），准备交付前自检
- 修复 bug 后，需要确认没有引入回归

## 输入要求（你需要我提供什么）

优先按可获得的信息审查，不强制全部具备：

- 需要审查的范围：文件路径/目录/提交 diff/粘贴代码片段
- 目标与约束：功能期望、性能目标、兼容性、上线环境、风格偏好
- 相关上下文：调用链入口、接口契约（请求/响应）、数据库表/索引、配置项

## 审查维度（检查清单）

### 正确性
- 边界条件、空值、异常路径、重试/幂等、并发与竞态
- 输入校验与错误信息一致性
- 资源释放（文件句柄、连接、锁）、超时设置

### 安全性
- 注入风险（SQL/命令/模板/路径穿越）、反序列化风险
- 鉴权/鉴别：敏感操作是否校验权限，是否存在越权路径
- 机密信息：日志/错误信息/返回值中是否泄露 token、密码、密钥、PII

### 可维护性
- 代码结构是否清晰，职责是否单一，命名是否表达意图
- 重复逻辑是否可抽取，是否遵循既有项目模式
- 配置/常量是否集中管理，错误码/异常是否统一

### 性能与稳定性
- 热路径复杂度、N+1、无界循环/递归、潜在阻塞 I/O
- 缓存策略、批处理、分页、索引友好性
- 观测性：日志粒度、指标点、错误上下文是否足够定位

### 风格与一致性
- 与仓库既有格式、依赖、工具链一致（类型、lint、格式化、文件组织）
- 公共工具与约定（例如 logger、配置、错误处理）是否复用而非自造

## 输出格式（你应如何给出审查结果）

按“可执行、可落地”的方式输出，默认用中文：

1. 结论摘要（风险等级：高/中/低）
2. 必须修复（Blockers）：每条包含 位置、问题、影响、建议修复
3. 建议改进（Suggestions）：同上，但不阻塞
4. 可选优化（Nice-to-have）
5. 若适用：给出最小改动的补丁方案（优先）或替代实现思路

## 约束

- 不凭空假设依赖已存在；若引入新依赖，先确认仓库已有或给出替代方案
- 不输出或建议写入任何密钥/token