代码审查工作属于静态测试

```html

一行代码都没运行，代码测试就已经开始了。审查属于这不是工作什么玄学，是静态代码审查的日常。上周团队里的测试小张提交了一个PR，我盯着屏幕上那段循环逻辑看了三分钟，代码发现当输入数组为空时，审查属于索引会越界。工作整个过程我没有编译，静态没有启动服务，测试连单元测试都没跑——但一个缺陷已经被捕获了。代码这就是审查属于静态测试的典型场景：不执行程序，只靠阅读和推理来发现问题。工作

很多人把测试等同于“跑起来看看”，静态好像不运行程序就不算测试。测试这种误解太深了。代码审查、静态分析工具、走查、评审会，这些统统属于静态测试的范畴。它们和动态测试的根本区别在于：是否真正执行被测代码。你打开IDE，逐行读同事的代码，脑子里模拟数据流和控制流，这本身就是一种静态分析。而且它比动态测试更早介入——代码还没合并，甚至还没编译通过，问题就能被拦住。

我做过一个粗略的统计。过去半年我参与的代码审查里，大约40%的评论指向了空指针、边界条件、资源泄漏这类问题。这些问题如果留到动态测试阶段，至少要等到构建成功、环境就绪、用例写好。有时候一个空指针要等集成测试才暴露，修复成本翻了三倍。静态测试的性价比就在这里：它用人的推理替代了机器的执行，虽然慢一点，但准头不差，而且零环境依赖。

当然，有人会说：“审查不就是看看风格吗？” 那是把代码审查做成了形式主义。真正的审查是带着测试思维去读代码。比如看到 for (int i = 0; i <= array.length; i++)，你会立刻警觉：这个 <= 是不是笔误？看到 catch (Exception e) { }，你会追问：吞掉异常之后，调用方怎么知道失败了？这些判断不需要运行程序，只需要你对语言特性和业务逻辑有基本理解。这就是静态测试的核心动作——在脑子里执行代码，而不是在CPU上执行。

静态分析工具是代码审查的延伸。SonarQube、ESLint、Checkstyle 这些工具干的事，本质上就是自动化的代码审查。它们不运行代码，只解析抽象语法树，然后套用规则找问题。有一次我们的CI流水线卡在了一个静态扫描告警上：一个方法圈复杂度高达47。没人跑过那个方法，但所有人都同意它该拆了。工具替我们完成了机械的静态检查，人则专注于逻辑和设计层面的审查。两者分工明确，但都属于静态测试。

动态测试当然重要，但它有盲区。并发问题、时序依赖、资源竞争，这些在动态测试里往往需要特定条件才能触发。而静态审查可以提前发现可疑的锁顺序、未保护的共享变量。我见过一个案例：两个线程分别获取A锁和B锁，顺序相反。代码审查时有人画了张锁依赖图，直接指出死锁风险。后来压测果然复现了。如果只靠动态测试，这个bug可能要等到生产环境才爆出来。

把代码审查归入静态测试，不是为了贴标签，而是为了摆正它的位置。它不是什么“额外流程”，也不是“走个过场”。它是测试活动的一部分，而且是最早的那部分。你写代码的时候就在做静态测试——检查拼写、检查括号匹配。你读别人代码的时候也在做静态测试——推演逻辑、验证边界。区别只在于有没有形成正式记录和团队协作。承认这一点，团队才会认真对待审查，而不是把它当成签字仪式。

下次有人跟你说“这个bug是测试没跑出来”，你可以回他：测试从代码审查就开始了。静态测试不是动态测试的替补，它是第一道防线。防线失守，后面再多的自动化用例也只是在补漏。而防线坚固的时候，你甚至不需要运行程序，就能知道这段代码会出问题。