凌晨两点十七分，漏洞我盯着屏幕上那个跳动的需修红色警告框，咖啡杯沿抵着下唇。漏洞系统又崩了——同一个漏洞，需修第三次。漏洞这次它带走了用户数据库里整整两万条记录。需修

漏洞当然要修。漏洞这问题压根不需要讨论。需修但真正让我失眠的漏洞，是需修另一件事：我们花了三周时间讨论“要不要修”，而不是漏洞“怎么修”。

事情是需修这样的。上个月安全团队提交了一份报告，漏洞说我们新上线的需修支付接口存在一个逻辑漏洞——攻击者可以通过修改请求参数，绕过金额校验。漏洞理论上，这能让用户以一分钱买走任何商品。报告写得清清楚楚，修复方案也附在末尾，预估工时四小时。

然后会议就开始了。

产品经理说，这个功能下周要上线，推迟修复会影响KPI。运营说，最近正在做促销活动，系统变更可能导致页面报错。市场部更直接：这事别声张，等活动结束再说。连技术主管都犹豫了——改动支付模块，万一引入新问题，谁负责？

会议室里，每个人都点头认同“应该修”，但每个人都希望别人先动手。那个红色警告框在投影仪上闪着，像一只慢慢膨胀的气球。

我后来才明白，大家讨论的根本不是漏洞，是风险分配。修错了，是我的锅；不修，出事了，是“安全团队报告过”的免责条款。每个人都在这场沉默的博弈里计算自己的损失，唯独没人计算那个漏洞一旦被利用，用户要损失什么。

三天后，气球破了。有人用那个漏洞刷走了库存里所有限量款，转手挂在二手平台。我们紧急下线系统，补丁打了上去，但损失已经造成了——不只是钱，还有用户那句“你们连这个都防不住”的失望。

那之后我养成一个习惯：每次收到漏洞报告，先问自己一个问题——如果这个漏洞明天就被利用，我能承受后果吗？如果不能，那就别废话，修。别管什么KPI，别管什么活动档期，更别管谁的面子。

漏洞这东西，就像墙上的裂缝。你看见它的时候，它已经存在很久了。你可以选择用海报遮住，假装看不见，但风一吹，海报会掉，裂缝会变成洞。到那时候，你面对的不再是一道墙的问题，而是整栋楼的结构安全。

技术圈有个说法叫“技术债”，意思是今天偷的懒，明天要连本带利还。但我觉得，漏洞比技术债更可怕——技术债是欠自己的，漏洞是欠用户的。你可以跟自己商量延期，但用户不会跟你商量原谅。

现在我的团队有个不成文的规定：高危漏洞，当天修，通宵也修。中危漏洞，最迟一周。低危的，排期修。没有例外。有人觉得我太死板，说这样会拖慢开发节奏。我只回一句：“你觉得是拖慢节奏好，还是半夜爬起来给用户道歉好？”

没人再反驳。

窗外的天开始泛白了。最后那个补丁在凌晨四点五十分部署完成，测试全部通过。我关掉监控页面，那上面跳动的数字终于安静下来。想抽根烟，摸了摸口袋，空的。算了。

漏洞需要修复吗？这个问题的答案，从来不在于代码，而在于你心里那杆秤——是把风险算清楚，还是把责任扛起来。