去年冬天，代码我盯着一段只有六行的评审Python函数看了整整四十分钟。它做了一件很简单的漏洞事——从配置字典里取一个键值，如果不存在就返回默认值。代码代码本身没毛病，评审逻辑也对。漏洞但问题出在它周围的代码上下文里：这个函数被三个模块调用，其中一个模块传进来的评审字典永远缺少那个键，而默认值恰好是漏洞空字符串。下游代码拿到空字符串后，代码会把它当成有效路径去拼接文件地址，评审最终在Windows上生成一个叫“C:\”的漏洞路径。没人发现，代码因为测试环境恰好用的评审是Linux。

这就是漏洞典型的代码评审漏洞——评审者盯着眼前的代码看，却没看见代码在真实系统里的影子。漏洞不在语法里，不在单个函数里，而在调用链的缝隙中。我见过太多评审记录，满屏都是“命名规范”“缩进不一致”“缺少注释”，但真正会炸的问题，往往被一句“逻辑没问题”轻轻放过。

代码评审最容易漏掉的第一类东西，是隐式契约。函数签名只说了参数类型是dict，没说这个dict必须包含哪些键。类型系统管不了这个，单元测试也未必覆盖。评审者默认“调用方会传对”，调用方默认“被调方会处理异常”。两边都这么想，裂缝就出来了。我后来养成一个习惯：看到任何接受字典、列表或对象作为参数的函数，先问一句——如果传进来的是空值、缺键、多了一层嵌套，这段代码会怎样？

第二类漏洞更隐蔽：并发时序。评审时我们习惯线性阅读代码，但生产环境是多线程的。一个看似无害的“先检查再写入”操作，在两次操作之间可能被另一个线程插进来。这种问题在评审里几乎不可能靠肉眼发现，除非评审者刻意去想“这段代码被两个请求同时执行会怎样”。我参与过的一个支付系统就栽在这上面——余额检查通过后，扣款前有大约3毫秒的窗口，高并发下重复扣款了十七次。代码评审时没人提这个问题，因为那段代码读起来太顺了。

第三类，也是我最想说的：评审者自身的认知盲区。一个人评审自己熟悉的领域，会不自觉地跳过某些检查。写Java的人看Python代码，会忽略GIL带来的并发差异；写前端的人审后端接口，会放过SQL注入的风险。这不是态度问题，是知识边界问题。我见过一个团队，所有评审都让同一个人做，因为他“经验最丰富”。结果他休假两周，代码质量直线下降——不是别人写得差，是没人能替代他的视角。评审需要多样性，不是因为礼貌，是因为不同背景的人会踩不同的坑。

怎么减少这些漏洞？我的做法很土：评审时强制自己写三句话。第一句，这段代码在什么条件下会出错。第二句，如果我是调用方，我会怎么误用它。第三句，这段代码和上周改的另一段代码有没有隐藏的耦合。写不出来就不点“通过”。这法子笨，但比“LGTM”有用得多。

还有一点，别把评审当考试。我见过太多评审变成挑格式毛病的大会，真正的逻辑问题反而没人敢提——因为提了显得你在质疑对方的能力。这种氛围下，漏洞不会消失，只会藏得更深。代码评审不是找茬，是给未来的自己留一条活路。你今天放过的一个空字符串，明天可能就是凌晨三点的告警电话。

最后说个真事。那个生成“C:\”路径的bug，后来被一个刚入职的实习生发现了。他没看代码，只是跑了一遍集成测试，发现文件创建失败。评审记录里，那段代码被四个人点过“通过”。漏洞不在代码里，在评审者的脑子里。