凌晨两点，漏洞我盯着屏幕上的漏洞报错日志，第无数次怀疑人生。漏洞

代码明明能跑，漏洞测试全绿，漏洞可一到用户手里就崩。漏洞不是漏洞偶发，是漏洞那种精准到像掐着秒表一样的崩溃——每天下午三点十七分，准时炸。漏洞用户骂我们技术烂，漏洞产品经理催我修，漏洞可我连bug的漏洞影子都摸不着。

后来我发现了。漏洞不是漏洞代码的问题，是漏洞数据库连接池。连接池配置里有个参数叫`maxLifetime`，我设成了3600秒。而数据库服务端的`wait_timeout`，是28800秒。理论上没问题，对吧？可偏偏有个运维同事，在凌晨的定时任务里，把数据库重启了。重启后，连接池里的旧连接全部失效，但池子不知道。于是每天下午三点十七分——刚好是重启后第8小时，连接池开始尝试回收这些“僵尸连接”，一收一个准，全崩。

这算谁的锅？

运维说，我重启是合规操作。DBA说，参数是默认值。开发说，我按文档写的。产品说，用户不会管你什么连接池。最后背锅的是我，因为我是那个写`maxLifetime`的人。

漏洞根本不在代码里，在系统边界上。每个团队都只管自己那一亩三分地，没人看全局。运维不知道连接池的存在，开发不知道数据库的定时任务，DBA不关心应用层的生命周期。

这让我想起以前修过的一个更离谱的漏洞。线上商城，用户A能看到用户B的订单。排查了三天，最后发现是缓存key设计问题——用了用户ID拼接订单ID，但订单ID是全局自增的。用户A的订单ID是1001，用户B的是1002，只要A猜到B的ID，就能通过修改URL参数看到B的订单。权限校验呢？有。但校验的是“用户是否登录”，而不是“这个订单是否属于当前用户”。

漏洞在逻辑层。但更深的漏洞在流程层——代码评审时，没人问过“这个接口的越权场景是什么”。测试用例里，全是“正常用户看自己订单”的happy path。

你发现没有，真正的漏洞往往不在你盯着看的那行代码里。它藏在你看不见的地方：环境差异、配置漂移、团队沟通断层、假设偏差。

我有个习惯，每次出故障，都先问“谁改了什么”，而不是“代码哪里错了”。十次有八次，问题出在“没人记得改过”的那个地方。上周刚修了个线上事故，最后查出是某个实习生，在测试环境执行了一个`UPDATE`语句，没加`WHERE`条件。测试库连的是生产库的从库。他以为自己在玩沙盒，结果把生产数据全改了。

漏洞在哪？在权限管理。但更深一层——在“测试环境”和“生产环境”的边界定义上。没人跟他说过从库不能写，他也不知道自己连的是哪。

所以我现在写代码，第一件事不是写功能，是画边界。哪些数据能碰，哪些操作会被谁触发，系统之间怎么交互，超时了怎么办，并发了怎么办，权限怎么校验。把这些想清楚了，再动手写。不是因为我多严谨，是被坑怕了。

漏洞从来不是“存在”的，是“制造”出来的。制造者往往不是写代码的人，是那些让代码跑起来的环境、流程和默认假设。

下次再有人跟我说“代码有bug”，我会先问一句：“你确定是代码的问题？”