代码审查清单

采用全面、结构化的方法来审查代码。系统地处理每个维度，而不是随意浏览。

安装

OpenClaw / Moltbot / Clawbot

npx clawhub@latest install code-review

审查维度

安全检查清单

审查每次变更是否存在以下漏洞：

• SQL注入— 所有查询均使用参数化语句或ORM；未将用户输入与字符串拼接
• 跨站脚本攻击— 用户提供的内容在渲染前已进行转义/净化处理；dangerouslySetInnerHTML或等效方法的使用经过论证且确保安全
• 跨站请求伪造防护— 状态变更请求需要有效的CSRF令牌；已设置SameSite Cookie属性
• 身份验证— 每个受保护的端点在处理前均验证用户是否已通过身份验证
• 授权— 资源访问权限限定于请求用户的权限范围；不存在不安全的直接对象引用漏洞
• 输入验证— 所有外部输入（参数、请求头、请求体、文件）均在服务端进行类型、长度、格式和范围的验证
• 密钥管理— 源代码中不包含API密钥、密码、令牌或凭据；机密信息来自环境变量或保险库
• 依赖安全— 新依赖来自可信来源，积极维护，且无已知CVE漏洞
• 敏感数据— 个人身份信息（PII）、令牌和机密信息绝不记录日志、包含在错误消息中或通过API响应返回
• 速率限制— 公共和认证端点均设有速率限制，以防止暴力破解和滥用
• 文件上传安全— 上传的文件需验证类型和大小，存储在Web根目录之外，并通过安全的Content-Type标头提供
• HTTP安全标头— 已设置内容安全策略（Content-Security-Policy）、X-Content-Type-Options、严格传输安全（Strict-Transport-Security）等标头

性能检查清单

• N+1查询— 数据库访问模式采用批处理或连接操作；避免在循环中执行单独查询
• 不必要的重新渲染— 组件仅在相关状态/属性变化时重新渲染；在可衡量的情况下应用记忆化技术
• 内存泄漏— 事件监听器、订阅、定时器和间隔在卸载/销毁时得到清理
• 包体积— 新依赖支持摇树优化；大型库动态加载；避免为单一功能导入完整库
• 懒加载— 重型组件、路由及首屏以下内容采用懒加载/代码分割
• 缓存策略— 对昂贵的计算和API响应采用适当的缓存策略（记忆化、HTTP缓存头、Redis）
• 数据库索引— 查询在索引列上进行过滤/排序；新查询已使用EXPLAIN进行检查
• 分页— 列表端点和查询使用分页或基于游标的获取；没有无限制的SELECT *
• 异步操作— 长时间运行的任务被卸载到后台作业或队列，而不是阻塞请求线程
• 图像与资源优化— 图像尺寸适当，使用现代格式（WebP/AVIF），并利用CDN进行交付

正确性检查清单

• 边界情况— 已处理空数组、空字符串、零值、负数和最大值等情况
• 空值/未定义处理— 访问前检查可为空的值；使用可选链或防护措施防止运行时错误
• 差一错误— 已验证循环边界、数组切片、分页偏移和范围计算
• 竞态条件— 对共享状态的并发访问使用锁、事务或原子操作
• 时区处理— 日期以UTC格式存储；显示转换在表示层进行
• Unicode与编码— 字符串操作处理多字节字符；文本编码明确（UTF-8）
• 整数溢出/精度— 对大数或货币的算术运算使用适当的类型（BigInt、Decimal）
• 错误传播—— 异步调用和外部服务的错误均被捕获并处理；Promise 永远不会被静默吞没
• 状态一致性—— 多步骤变更具有事务性；部分失败时系统仍保持有效状态
• 边界验证—— 对有效范围边界值（最小值、最大值、临界值）进行测试

可维护性检查清单

• 命名清晰性—— 变量、函数和类使用能揭示意图的描述性名称
• 单一职责—— 每个函数/类/模块只做一件事；对单一关注点的修改不会波及无关代码
• DRY原则（不要重复自己）—— 重复逻辑被提取到共享工具中；复制粘贴的代码块被整合
• 圈复杂度—— 函数具有较低的分支复杂度；深度嵌套链被重构
• 错误处理—— 在适当边界捕获错误，记录上下文信息，并以有意义的方式呈现
• 死代码清理—— 移除被注释的代码、未使用的导入、不可达分支和过时的功能开关
• 魔法数字与字符串—— 字面值被提取为具有明确语义的命名常量
• 模式一致性—— 新代码遵循代码库中已建立的约定
• 函数长度— 函数应短小精悍，便于一目了然；过长的函数需进行分解
• 依赖方向— 依赖指向内层（从基础设施指向领域层）；核心逻辑不应导入UI层或框架层

测试清单

• 测试覆盖率— 新的逻辑路径应有相应测试；关键路径需同时包含正常路径和失败场景测试
• 边界情况测试— 测试需覆盖边界值、空输入、空值及错误条件
• 无脆弱测试— 测试应具有确定性；不依赖时序、外部服务或共享可变状态
• 测试独立性— 每个测试独立设置并清理自身状态；测试顺序不影响结果
• 有意义断言— 测试应针对行为与结果进行断言，而非实现细节
• 测试可读性— 测试遵循"准备-执行-断言"模式；测试名称需描述场景与预期结果
• 模拟规范— 仅对外部边界（网络、数据库、文件系统）进行模拟
• 回归测试— 缺陷修复需包含能复现原始缺陷并证明其已解决的测试

审查流程

分三轮通读代码。切勿试图一次性发现所有问题。

第一遍（2-5分钟）

1. 阅读PR描述和相关议题
2. 浏览文件列表——变更范围是否合理？
3. 检查整体方案——这是否是解决问题的正确方法？
4. 确认变更不会引入架构偏离

第二遍（审查主要耗时）

1. 从上至下阅读每个文件的差异
2. 对照上方清单检查每个函数变更
3. 在每个I/O边界验证错误处理
4. 标记任何让你犹豫的内容——相信你的直觉

第三轮检查（5分钟）

1. 思考在生产环境中可能出现的问题
2. 检查标记的代码路径是否缺少测试
3. 验证回滚安全性——此变更能否在不丢失数据的情况下回退？
4. 确认文档和更新日志已根据需要进行更新

严重级别

按严重级别对每条评论进行分类，以便作者了解哪些内容会阻碍合并。

始终在你的评审意见前加上严重性标签。这能消除关于哪些事项重要的模糊性。

提供反馈

原则

• 具体明确— 指向具体行并解释问题，而不仅仅是说“这是错的”
• 解释原因— 说明风险或后果，而不仅仅是规则
• 建议修复方案— 尽可能提供具体的替代方案或代码片段
• 询问而非命令— 对于主观性问题使用提问方式：“你觉得……怎么样？”
• 肯定好的工作— 指出简洁的解决方案、巧妙的优化或全面的测试
• 区分阻塞性与非阻塞性问题— 使用严重性标签，让作者知道什么重要

评论示例

差评示例：

这是错的。改掉它。

好评示例：

[严重]此查询将用户输入直接内插到SQL字符串中（第42行），这容易受到SQL注入攻击。请考虑使用参数化查询：

SELECT * FROM users WHERE id = $1

差评示例：

你为什么没加测试？

好评示例：

[次要]新的calculateDiscount()函数有几个分支路径——我们能否为零数量和负价格的边界情况添加测试，以防止回归问题？

差评示例：

我本会用不同的方式处理这个。

好评示例：

[吹毛求疵]这种方法效果不错。另一种方案是将重试逻辑提取到一个共享的withRetry()包装函数中——但这是可选的，可以作为后续改进。

代码审查反模式

避免这些既浪费时间又损害团队信任的常见陷阱：

绝不要做

1. 绝不要未阅读每一行修改就批准——橡皮图章式审查比不审查更糟
2. 绝不要仅因风格偏好而阻塞拉取请求——使用代码检查工具；人负责审查逻辑
3. 绝不要留下未标明严重程度的反馈——模糊不清会导致无谓的循环
4. 绝不要只要求修改而不解释原因——"修复这个"毫无教育意义
5. 绝不要一次性审查超过400行代码——理解力会急剧下降；将大型拉取请求分多次审查
6. 绝不要跳过安全检查清单——一个遗漏的漏洞胜过一百个风格小问题
7. 绝不要人身攻击——审查代码，而非编码者；始终假设对方出于善意