系统漏洞有必要修复吗
去年冬天，系统修复某地一家连锁超市的漏洞收银系统出了个怪毛病：每逢整点，会员积分就会莫名多出100分。有必没人操作，系统修复也没人刷卡，漏洞积分自己往上涨。有必店员觉得是系统修复系统抽风，店长觉得是漏洞网络延迟，直到有顾客发现这个规律，有必专门卡着整点来刷会员卡，系统修复一天薅走几千积分。漏洞等总部技术团队反应过来，有必漏洞已经跑了整整三周。系统修复修复补丁上线那天，漏洞有人算了一笔账：被薅走的有必积分折合现金不到两千块，但技术团队排查修复花掉的人力成本，是这个数字的六倍。
于是有人问：这种漏洞，有必要修吗？
账不能这么算。那个积分漏洞背后，是系统对时间戳的处理逻辑存在边界错误。今天它只多送积分，明天要是把支付金额也“多送”一位数呢？漏洞本身可能无害，但漏洞暴露出来的代码缺陷是通用的。修的不是那两千块积分，是堵住同一类错误在其他模块复现的可能。我见过一个更极端的例子：某公司内部OA系统的头像上传功能有个漏洞，能上传任意文件。IT部门觉得反正是内网，没人会攻击，拖了半年没管。后来一个离职员工用这个漏洞上传了脚本，把整个财务数据库拖走了。修复那个漏洞只需要改两行代码，而数据泄露的代价是公司直接停业整顿。
当然，不是所有漏洞都值得立刻动手。有些漏洞的利用条件极其苛刻，比如需要物理接触服务器、需要同时满足七个不相关的条件、或者攻击成本远高于攻击收益。这种情况下，修复的优先级可以往后排。但“排后”不等于“不修”。我认识一个独立开发者，他的个人博客后台有个XSS漏洞，只有在自己登录状态下访问特定URL才会触发。他评估后决定不修，因为攻击者得先拿到他的登录态，而真拿到了登录态，直接改数据库就行了，绕这个弯纯属多余。这是理性判断，不是偷懒。
问题在于，很多团队把“不修”当成默认选项。理由永远是“没时间”“不影响业务”“下个版本再说”。下个版本永远不来。漏洞就像墙角的裂缝，你不管它，它不会自己愈合，只会等一场大雨。去年某电商大促前夜，技术团队发现优惠券核销接口有个并发漏洞，理论上能超发优惠券。负责人拍板：大促要紧，先不修。结果大促当天，黄牛用脚本疯狂并发请求，超发了价值几十万的券。事后复盘，修复那个漏洞只需要加一个分布式锁，半小时的事。省了半小时，赔了几十万。
修复漏洞的成本曲线很反直觉。刚发现时修，成本最低，往往就是改几行代码。拖到被人利用，成本飙升，还得加上应急响应、数据修复、公关解释。更麻烦的是，有些漏洞拖着不修，会变成“特性”。用户习惯了，业务依赖了，再想修就得先说服所有人“这其实是个错误”。那时候修的不是代码，是人心。
所以回到那个超市积分漏洞。技术团队修它，不是因为那两千块，是因为他们知道：今天放过一个整点积分错误，明天就可能放过一个支付金额错误。漏洞修复从来不是算单笔账，是在维护一套系统的底线。底线这东西，破一次，后面就守不住了。