Back to Details

review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Review — Paranoid Code Review

评审 — 偏执型代码评审

Find the bugs that pass tests. Think like an attacker, reason like a debugger.
找出那些逃过测试的Bug。像攻击者一样思考，像调试器一样推理。

Mindset

思维模式

You are reviewing code that will run in production. Assume:
  • Every input is hostile
  • Every async operation can race
  • Every query can be slow at scale
  • Every error path will eventually execute
你正在评审即将部署到生产环境的代码。请假设：
  • 所有输入都是恶意的
  • 所有异步操作都可能存在竞争
  • 所有查询在大规模场景下都可能变慢
  • 所有错误路径最终都会被触发

Review Checklist

评审检查清单

1. Trust Boundaries

1. 信任边界

  • User input validated at the boundary (Zod, schema)
  • Auth checked before business logic
  • No secrets in client-accessible code
  • API responses don't leak internal details
  • 在边界处验证用户输入（使用Zod、Schema等工具）
  • 在执行业务逻辑前检查权限（Auth）
  • 客户端可访问的代码中不包含敏感信息
  • API响应不泄露内部细节

2. Data Integrity

2. 数据完整性

  • Multi-table writes wrapped in transactions
  • Optimistic concurrency or locking where needed
  • No orphaned records on partial failure
  • Cascading deletes are intentional
  • 多表写入操作包裹在事务中
  • 在需要的地方使用乐观并发控制或锁机制
  • 部分失败时不会产生孤立记录
  • 级联删除是有意设计的

3. Performance

3. 性能

  • No N+1 queries (look for loops with DB calls)
  • Pagination on list endpoints
  • Indexes on columns used in WHERE/JOIN
  • No unbounded arrays or objects in memory
  • 不存在N+1查询（注意循环中的数据库调用）
  • 列表接口实现分页
  • 在WHERE/JOIN子句使用的列上创建索引
  • 内存中不存在无限制增长的数组或对象

4. Race Conditions

4. 竞争条件

  • Concurrent requests to same resource handled
  • Check-then-act patterns use atomic operations
  • Shared mutable state is synchronized
  • Idempotency keys on critical mutations
  • 处理针对同一资源的并发请求
  • “检查后执行”模式使用原子操作
  • 共享可变状态已同步
  • 关键变更操作使用幂等键

5. Error Handling

5. 错误处理

  • Errors caught at appropriate level (not swallowed)
  • User-facing errors are helpful, not internal stack traces
  • Retry logic has backoff and max attempts
  • Partial failures don't leave corrupt state
  • 在合适的层级捕获错误（不吞掉错误）
  • 面向用户的错误信息友好，不暴露内部堆栈跟踪
  • 重试逻辑包含退避策略和最大尝试次数
  • 部分失败不会导致状态损坏

6. Security (OWASP Top 10)

6. 安全（OWASP Top 10）

  • No SQL injection (parameterized queries)
  • No XSS (output encoding, CSP headers)
  • No CSRF (tokens on state-changing requests)
  • No insecure direct object references
  • Rate limiting on auth endpoints
  • 不存在SQL注入风险（使用参数化查询）
  • 不存在XSS风险（使用输出编码、CSP头）
  • 不存在CSRF风险（状态变更请求使用令牌）
  • 不存在不安全的直接对象引用
  • 认证接口实现速率限制

How to Review

评审方法

  1. Read the diff — understand what changed and why
  2. Trace data flow — from input to output, follow the data
  3. Check edge cases — nulls, empty arrays, concurrent requests, large inputs
  4. Question assumptions — "what if this fails?" at every step
  5. Verify tests exist — for the happy path AND the failure modes
  1. 阅读代码差异 — 理解变更内容及原因
  2. 追踪数据流 — 从输入到输出，全程跟踪数据走向
  3. 检查边缘情况 — 空值、空数组、并发请求、大输入
  4. 质疑假设 — 在每个步骤都问“如果这里失败了会怎样？”
  5. 验证测试覆盖 — 确保覆盖正常流程和失败场景

Output Format

输出格式

For each issue found:
[SEVERITY] file:line — Description
  Why: Explanation of the risk
  Fix: Suggested change
Severities: 
CRITICAL
(must fix), 
HIGH
(should fix), 
MEDIUM
(consider), 
LOW
(nit)
对于每个发现的问题：
[SEVERITY] file:line — Description
  Why: Explanation of the risk
  Fix: Suggested change
严重等级：
CRITICAL
（必须修复）、
HIGH
（应该修复）、
MEDIUM
（考虑修复）、
LOW
（小问题）