code-review-pro

代码审查 Pro

找出真正重要的问题，逐一证明，并给出修复方案。简短列出确凿问题，胜过长篇罗列各种可能性。

工作流

1. 确定审查范围。 判断审查对象：粘贴的代码片段、特定文件、工作树差异（git diff、git diff --staged），或分支与其基准分支的差异（git diff main...HEAD）。审查差异时，检查改动的代码行，同时阅读足够的上下文，了解这些代码如何被调用。

2. 先了解上下文，再做判断。 确认语言、框架和版本（查看 package.json、pyproject.toml、go.mod 等），了解代码如何被触发（HTTP 处理程序、作业、CLI、库）、哪些输入不可信，以及仓库的约定（代码检查工具、CLAUDE.md、现有模式）。一种模式在某个框架中可能是漏洞，在另一个框架中却是安全的；例如，React 会转义 JSX 文本，因此 XSS 风险存在于 dangerouslySetInnerHTML、href 值和原始 HTML 接收点中。

3. 按优先级审查，使用 references/checklist.md：

   1. 安全性
   2. 正确性和边界情况
   3. 性能
   4. 可维护性和约定

4. 报告前验证每项发现。 对每个候选问题追踪数据流：输入来自哪里，攻击者或真实用户能否控制它，上游是否已对其进行验证或转义？检查是否有测试覆盖该问题。如果能运行代码，就用小型测试或脚本复现问题。删除无法证实的发现；对其余发现标明置信度。

5. 按严重程度排序，并按以下格式撰写报告。 最高严重程度的问题放在最前面。将同一问题的重复实例合并为一项发现，并列出所有位置。

严重程度

• Critical - 可立即被利用，或会导致数据丢失／损坏：使用用户输入进行注入、绕过身份验证、代码中包含机密信息、真实数据的访问控制失效。
• High - 在现实条件下很可能出现的漏洞或错误：共享状态上的竞态、缺少授权检查、面向用户的路径上查询无界、吞掉错误导致故障被隐藏。
• Medium - 当前可正常工作，但不够稳健：受信任调用方之后缺少输入验证、小规模数据上的 N+1 查询、状态所有权不明确。
• Low - 风格、命名、小幅简化。最多报告少数几项；跳过代码检查工具或格式化工具已能强制执行的问题。

输出格式

# Code Review: [scope]

**Verdict**: [Ship / Ship after fixes / Do not ship] - [one sentence why]
**Findings**: [n] critical, [n] high, [n] medium, [n] low

## Critical

### 1. SQL injection in user search (`src/api/users.ts:42`)
**Category**: A05:2025 Injection | **Confidence**: High
**Evidence**: `q` comes from `req.query` and is interpolated into the SQL string; no validation upstream.
**Impact**: Any caller can read or modify arbitrary tables.

Current:
```ts
const rows = await db.query(`SELECT * FROM users WHERE name LIKE '%${q}%'`);
```

Fix:
```ts
const rows = await db.query("SELECT * FROM users WHERE name LIKE $1", [`%${q}%`]);
```

## High
...

## Medium
...

## Low
- `utils/date.ts:10` - [one line]

## What is solid
[Two or three specific things done well, so the author knows what to keep.]

## Not reviewed
[Files, paths, or concerns outside scope or that could not be verified.]

导致审查结果不佳的陷阱

• 不阅读调用方就报告。 “缺少验证”往往是因为上游某一层已经进行了验证。标记问题前先检查。
• 泛泛而谈。 “建议添加错误处理”不算一项发现。要指出具体故障：哪个调用会抛出异常、用户会看到什么、会留下什么状态。
• 把风格问题当成严重问题。 行长、括号位置或个人偏好绝不应高于 Low。
• 沿用过时规则。 根据项目使用的版本进行检查：启用 React Compiler 后，关于 useMemo／useCallback 的建议会有所不同；许多 Node API 现在也已内置（fetch、crypto.randomUUID、node:test）。
• 给出无法编译的修复方案。 每个“Fix”代码块都必须符合仓库中语言和版本的语法。如果不确定，就如实说明。
• 问题过多。 发现超过约 15 项，会掩盖关键问题。将次要问题汇总为一行。