很多人把“漏洞”和“bug”当成同义词换着用。我一开始也这样，漏洞直到有次面试被面试官追问“你觉得Log4j那个算漏洞还是漏洞bug”，我才发现这俩词儿分得没那么简单。漏洞

先说一个我亲身经历的漏洞小事。几年前我写过一个用户登录模块，漏洞逻辑很简单：查数据库，漏洞比对密码哈希，漏洞返回token。漏洞上线跑了两周，漏洞没出问题。漏洞结果有天凌晨三点被运维电话叫醒，漏洞说有人用空密码登进了管理员账号。漏洞我爬起来看代码，漏洞发现是漏洞数据库连接池耗尽时，查询返回了null，而我的判断写成了if (user == null || user.passwordHash == null) return true;——那个return true是我调试时随手写的，忘了删。这玩意儿算bug还是漏洞？我当时在复盘文档里写的是“逻辑bug”，但安全团队把它归类为“认证绕过漏洞”。同一个东西，两个名字。

仔细想想，bug这个词诞生得早多了。1947年哈佛马克II计算机里那只飞蛾，被贴进日志本，旁边写着“First actual case of bug being found”。从那以后，任何程序行为不符合预期，程序员都叫它bug。它是个工程词汇，带着点自嘲和日常感。你写了个循环少加了个等号，数组越界了，页面白屏了——这些都是bug。它们不一定有害，有时候只是烦人，比如按钮点下去没反应，或者数字格式化多了一位小数。

漏洞不一样。漏洞这个词自带威胁模型。它默认存在一个攻击者，这个攻击者会主动利用某个缺陷来达成恶意目的。你写了个strcpy没检查长度，如果只是自己本地跑着玩，那是个bug；一旦这个函数处理的是网络数据包，攻击者能构造超长输入覆盖栈上的返回地址，它就变成了缓冲区溢出漏洞。区别不在代码本身，在于有没有人想害你。

我观察到一个挺有意思的现象：安全圈的人喜欢把漏洞叫“漏洞”，开发圈的人喜欢把漏洞叫“bug”。你去翻CVE（通用漏洞披露）数据库，每个条目都叫“vulnerability”，描述里却经常写“due to a bug in...”。这种混用不是谁对谁错，而是视角差异。开发者的视角是“我的代码没按我想的运行”，安全人员的视角是“这段代码能被别人用来干坏事”。

再往深了说，漏洞往往是一类特殊的bug——那些能被武器化的bug。但不是所有bug都能变成漏洞。比如你的App在iOS 17上闪退，这是个bug，但它很难被远程利用，除非攻击者能让你主动打开某个特定页面。反过来，有些漏洞甚至不是bug。比如设计缺陷：某个API允许用户枚举用户名，因为登录失败时返回“用户不存在”而不是“用户名或密码错误”。代码逻辑完全正确，没有一行写错，但攻击者能拿它来撞库。这种叫“设计漏洞”，你没法通过改一行代码修掉，得重新设计整个认证流程。

还有个更微妙的区别：bug通常有确定的修复方式。你找到那行写错的代码，改掉，测试通过，完事。漏洞的修复往往牵扯更多。比如心脏出血漏洞（Heartbleed），根因是OpenSSL里一个缺少边界检查的memcpy——从代码角度看就是个bug。但修复它不仅要改那行代码，还要通知所有依赖OpenSSL的厂商、重新签发证书、评估数据泄露范围。bug是点，漏洞是面。

我自己的习惯是：跟开发同事沟通时说“这里有个bug”，跟安全团队同步时说“这里有个漏洞”。不是矫情，是这两个词激活的思维模式不一样。说bug的时候大家想的是“怎么修”，说漏洞的时候大家想的是“谁可能利用、影响多大、要不要发公告”。

所以下次你听到有人把这两个词混着用，不用纠正他。但你自己心里得清楚：你写的那个空指针解引用，如果只是让程序崩溃，那是个bug；如果攻击者能通过它读取内存里的密钥，那就是漏洞。同一行代码，两种命运。取决于有没有人盯着它，以及那个人想干什么。