bug和漏洞的区别

前阵子帮一个朋友看他们公司的代码仓库，发现提交记录里混着“修复bug”和“修复漏洞”两种写法。漏洞我问他这俩有什么区别，漏洞他愣了一下说：“不都一样吗？漏洞反正都是改代码。”这种混淆其实挺常见，漏洞连不少开发者都默认bug和漏洞是漏洞同一回事。但如果你在安全团队待过，漏洞就知道这两个词背后完全是漏洞两种工作流、两种心态，漏洞甚至两种法律责任。漏洞

先说我自己的漏洞一个判断：bug是“东西没按预期工作”，漏洞是漏洞“东西按预期工作了，但预期本身有问题”。漏洞 这句话有点绕，漏洞但举个例子就清楚了。漏洞

2017年，我参与过一个电商App的测试。当时有个优惠券功能，用户领券后如果快速连续点击“使用”按钮，系统会重复扣减库存，导致超卖。从产品逻辑上讲，这明显是个bug——按钮应该防重复提交，或者后端要做幂等。开发修了三天，加了防抖和数据库唯一索引，问题解决。这叫bug修复。

但同一个App，还有另一个问题：用户可以在不登录的情况下，通过修改URL里的用户ID参数，直接查看别人的订单详情。这个功能“按预期工作”了——它确实返回了订单数据，代码逻辑没写错。但问题出在权限校验的缺失上。这不是代码写错了，而是设计时压根没考虑“用户A不能看用户B的订单”。这就是漏洞。它不会导致程序崩溃，不会报错，甚至测试用例里如果只测正常流程，根本发现不了。但它能被恶意利用。

所以你看，bug通常影响的是功能可用性，而漏洞影响的是系统安全性。一个让用户用不了，一个让用户被坑了还不知道。

再往深一层说，bug的发现路径往往是“测试→复现→定位→修复→回归”。漏洞的发现路径更接近“攻击→利用→分析→修补→加固”。前者是工程问题，后者是攻防问题。我见过太多团队把漏洞当bug修——比如SQL注入，开发改了个参数过滤就提交了，结果换个注入点又中招。因为漏洞的根因往往是架构层面的信任边界模糊，不是某个函数写错了。

还有个更实际的区别：bug可以容忍，漏洞不能。 一个后台管理系统的分页按钮点快了会卡住，这是bug，用户骂两句但还能用。但如果这个分页接口没做权限校验，普通用户能通过它拉到所有用户数据，这就是漏洞，得立刻发版修，还得评估数据泄露范围、通知监管。前者是排期里的普通任务，后者是凌晨三点拉你起来干活的P0事故。

我印象很深的一次，某开源项目修了一个“bug”：数组越界导致崩溃。提交者只改了边界判断。但安全研究员一看，这个越界读其实能泄露内存里的密钥。同一个代码改动，在bug视角下是“修复崩溃”，在漏洞视角下是“修复信息泄露”。视角不同，严重性评级天差地别。

日常沟通里，我习惯把这两个词分得很清。跟产品经理说“有个bug”，意思是功能不对劲，你排个期。跟安全负责人说“有个漏洞”，意思是别排期了，现在就拉群。混用这两个词，轻则沟通效率低，重则把安全事件当普通故障处理，最后捅出大篓子。

当然，现实里边界没那么干净。有些bug本身就是漏洞的入口，有些漏洞利用起来表现得像bug。但心里得有一根弦：当你发现一个“奇怪的行为”时，先问自己——这是代码没写对，还是代码写对了但规则本身有洞？答案不同，后续动作完全不同。

下次提交代码时，不妨看一眼commit message。写“fix bug”还是“fix vulnerability”，不只是措辞问题，它暴露了你对问题的理解深度。