凌晨两点，检查我盯着屏幕上那行红色的代码报错信息，咖啡杯沿已经结了一层干涸的漏洞奶渍。这是检查本周第三次因为同样的空指针异常被测试组打回。代码看起来没问题——对象明明判了空，代码逻辑也走通了，漏洞可一跑起来就崩。检查后来我逐行打印日志才发现，代码问题出在一个毫不起眼的漏洞equals()方法上：两个对象的值一样，但类型不同，检查一个是代码String，一个是漏洞StringBuilder转出来的字符串，equals()直接返回了false。检查

这种蠢事每天都在发生。代码检查代码漏洞，漏洞说白了就是跟自己较劲。你以为写对了，其实编译器早就给你挖好了坑。最常见的坑反而不是那些复杂的并发问题或算法缺陷，而是最基础的边界条件——数组越界、整数溢出、空值处理。我见过一个支付系统，金额用int存，结果某天用户买了3亿件单价1元的商品，系统直接溢出成负数，账目对不上，客服电话被打爆。修复只需要把int改成long，但没人会提前想到有人真的买3亿件商品。

代码漏洞的本质是预期和现实的错位。你预期用户输入的是手机号，结果他粘贴了一段表情符号；你预期文件一定存在，结果磁盘被拔了；你预期接口返回的字段非空，结果对方升级版本后改了结构。这些漏洞不靠静态分析工具能全找出来，工具只能抓明显的语法错误和模式匹配。真正的漏洞藏在业务逻辑的缝隙里，藏在那些你“觉得没问题”的假设里。

有个朋友跟我分享过他的习惯：每次写完代码，他会故意用最刁钻的输入去测自己的函数。传null、传空字符串、传超长字符串、传负数、传非法日期。他说这叫“把自己当黑客”，专挑自己代码里最脆弱的部分下手。这招确实有效——他负责的模块上线后bug率常年低于团队平均水平。但代价是写代码的时间要多出三分之一，很多人嫌麻烦不愿意干。

我自己的经验是，检查代码漏洞要分三层看。第一层是语法和类型错误，编译器能帮你挡掉大部分。第二层是资源管理和异常处理，比如数据库连接有没有关、文件流有没有释放、catch块里有没有吞掉真正的异常。第三层才是逻辑漏洞，这层最费神，需要你把代码在脑子里跑一遍，模拟各种可能的输入路径。有时候盯着屏幕看半天看不出问题，但出去倒杯水回来，突然就想到某个分支没覆盖。

有个项目让我印象特别深。那是一个数据同步功能，开发了三天，测试了五天，所有人都觉得稳了。结果上线第二天，用户反馈某天的数据少了一条。查了半天，发现是时间戳的时区问题——服务器在东八区，数据库存的是UTC时间，同步时直接拿字符串比较，没做转换。就这一个漏洞，差点让客户解约。后来我们在代码里加了时区转换的工具类，并且强制所有时间字段都用DateTime类型，不准用裸字符串。

检查代码漏洞没有终点。每次修复一个bug，你都会对系统多一层理解，但同时也可能引入新的问题。就像拆炸弹，剪错一根线就全完了。最好的办法是保持敬畏——别觉得自己写的是完美的代码，也别完全相信测试报告。写代码的时候多问自己一句：如果用户乱来怎么办？如果网络断了怎么办？如果数据格式变了怎么办？这三个问题能帮你挡住一大半的漏洞。

当然，工具还是要用的。IDE自带的静态检查、SonarQube、FindBugs这些，能扫出不少低级错误。但工具只是辅助，最后的把关人还是你自己。我见过有人靠工具扫完就以为万事大吉，结果上线第一天就崩了——因为工具不会告诉你，你的业务逻辑和需求文档描述的根本不是一回事。

这行干久了，你会发现漏洞是写代码的一部分。就像开车难免刮蹭，但老司机能预判风险，提前减速打方向。检查代码漏洞也一样，靠的是经验积累和对细节的敏感。别指望一次写对，也别指望工具全包。老老实实读自己的代码，带着怀疑的眼光去审每一行，比什么都强。