Review Lens

只检查代码风格的代码审查，就像对勒索信做拼写检查。语法没问题——内容才是问题所在。

功能概述

人类审查者擅长发现风格问题、明显缺陷和高层设计问题。但他们不擅长发现：

• - 每百万次请求才出现一次、但一旦出现就会损坏数据的边界情况
• 隐藏在 <= 中本应是 < 的差一错误
• 两个总是足够快的操作之间的竞态条件
• 错误被捕获、记录后……函数却若无其事继续执行的静默失败
• 假设输入总是已排序、非空、UTF-8 编码的隐含假设

Review Lens 通过七个专门的透镜检查代码，捕捉人类容易忽略的问题。

七个透镜

透镜 1：边界分析

检查项：
├── 空输入：数组为 [] 会怎样？字符串为 会怎样？映射为 {} 会怎样？
├── 单元素：如果只有一个元素会怎样？
├── 最大输入：如果有数百万个元素会怎样？
├── 空值/未定义：如果有参数为 nil 会怎样？
├── 零值：如果数字为 0 会怎样？负数？NaN？无穷大？
├── Unicode：如果字符串包含表情符号、从右到左字符或零宽字符会怎样？
├── 并发：如果两个线程同时调用此函数会怎样？
└── 时间：如果在午夜运行会怎样？在 2 月 29 日？在夏令时转换期间？

它能发现的问题：
javascript
// 人类审查者：看起来不错，正确计算平均值
function average(numbers) {
return numbers.reduce((a, b) => a + b) / numbers.length;
}
// Review Lens：空数组 → reduce 抛出 TypeError。
// 单元素 → 正常工作。
// 非常大的数组 → 潜在的浮点累积误差。
// 包含 NaN 的数组 → 结果为 NaN（静默数据损坏）。

透镜 2：失败路径分析

检查项：
├── 每个错误都被捕获了吗？（不仅仅是预期的错误）
├── 当错误被捕获时，函数是否仍能正确运行？
│ └── 它返回合理的值吗？还是返回 undefined/null？
├── 错误消息有用吗？（包含上下文，不仅仅是出错了）
├── 错误是否正确传播？（没有被吞没，没有被重复处理）
├── 失败时副作用是否被清理？（事务回滚、文件关闭、锁释放）
└── 调用者能否区分无结果和错误？

它能发现的问题：
python

人类审查者：不错，处理了错误情况

Review Lens：调用者收到 None，但无法区分是用户不存在

还是数据库宕机。这两种情况本质上是不同的。

调用者无法区分用户缺失和系统故障。

另外：如果 user_id 被记录且包含 PII——日志目标是否符合 PII 合规要求？

透镜 3：状态转换分析

检查项：
├── 所有状态转换是否有效？（没有无效的中间状态）
├── 状态是否原子更新？（没有对其他线程可见的半更新状态）
├── 状态转换是否可能乱序发生？
├── 是否存在永远无法退出的状态？（死锁、无限循环）
├── 清理是否得到保证？（finally 块、defer、析构函数）
└── 布尔标志是否正确使用？（没有多个布尔值创建无效组合）

它能发现的问题：
java
// 人类审查者：订单状态机，看起来完整
order.setStatus(processing);
payment.charge(order.getTotal());
order.setStatus(paid);
inventory.reserve(order.getItems());
order.setStatus(confirmed);

// Review Lens：如果 payment.charge() 成功但 inventory.reserve()
// 失败，订单将卡在paid状态且无库存。
// 客户已付款但订单无法履行。无回滚机制。
// 另外：在 setStatus(processing) 和 charge() 之间，
// 订单处于看似正在处理但尚未扣款的状态——如果进程在此处崩溃，
// 它将永远停留在processing状态，且无重试机制。

透镜 4：隐含假设分析

检查项：
├── 排序假设：是否假设输入已排序？
├── 唯一性假设：是否假设没有重复项？
├── 格式假设：是否假设特定的编码、区域设置、时区？
├── 大小假设：是否假设数据适合内存？
├── 时序假设：是否假设操作足够快完成？
├── 环境假设：是否假设特定的操作系统、权限或网络？
├── 依赖假设：是否假设特定版本的库？
└── 业务假设：是否假设可能变化的规则？

它能发现的问题：
go
// 人类审查者：简洁的函数，结构良好
func findUser(email string) (*User, error) {
results, err := db.Query(SELECT * FROM users WHERE email = ?, email)
if err != nil {
return nil, err
}
return results[0], nil // 返回第一个匹配项
}

// Review Lens：假设 email 是唯一的（未检查 UNIQUE 约束）。
// 假设至少存在一个结果（空 results[0] 会引发 panic）。
// 假设大小写敏感性与数据库排序规则匹配。
// 假设 email 已修剪（尾部空格可能导致不匹配）。
// SELECT * 拉取所有列——模式更改会破坏结构映射。

透镜 5：性能悬崖分析

检查项：
├── N+1 查询：循环中每次迭代都进行数据库调用
├── 无界增长：无限制增长的集合
├── 缺少分页：返回所有结果的查询
├── 二次（或更差）算法：对相同数据的嵌套循环
├── 不必要的分配：在热循环中创建对象
├── 缺少短路：可以提前退出的昂贵操作
├── 序列化：为每个请求序列化大对象
└── 正则表达式：灾难性回溯模式

它能发现的问题：
javascript
// 人类审查者：获取所有活跃用户及其订单，看起来没问题
async function getActiveUsersWithOrders() {
const users = await db.query(SELECT * FROM users WHERE active = true);
for (const user of users) {
user.orders = await db.query(SELECT * FROM orders WHERE user_id = ?, user.id);
}
return users;
}

// Review Lens：N+1 查询模式。100 个用户：101 次查询。
// 10,000 个用户：10,001 次查询。无分页——将所有活跃用户
// 加载到内存中。两个表都选择了所有列。
// 大规模时：10 秒响应时间，潜在 OOM，数据库连接池耗尽。
// 在开发环境中使用 12 个测试用户时工作正常。

透镜 6：安全面分析

检查项：
├── 输入信任：用户输入在使用前是否经过验证？
├── 输出编码：输出是否针对目标上下文进行了转义？
├── 身份验证：调用者的身份是否已验证？
├── 授权：调用者是否被允许执行此特定操作？
├── 注入：用户输入能否改变查询、命令或模板？
├── 信息泄露：错误消息是否暴露了内部细节？
├── 时序：响应时间能否泄露秘密？
└── TOCTOU：检查权限和执行操作之间是否存在间隙？

透镜 7：变更下的正确性

检查项：
├── 魔法数字：有人会理解为什么这是 86400（秒/天）吗？
├── 隐式顺序：如果有人重新排序这些行，会破坏代码吗？
├── 命名漂移：如果行为改变，名称是否仍然匹配？
├── 接口脆弱性：向结构体添加字段会破坏此代码吗？
├── 复制粘贴陷阱：此代码是否与附近可能分化的代码相似？
└── 删除安全性：如果有人删除此代码依赖的函数，错误信息是否清晰？

审查输出格式

╔══════════════════════════════════════════════════════════════╗
║ REVIEW LENS ║
║ 文件：src/checkout/payment.ts ║
║ 变更行数：47（+32 / -15） ║
╠══════════════════════════════════════════════════════════════╣
║ ║
║