凌晨两点，漏洞我盯着屏幕上的产生404错误页面，咖啡已经凉透。漏洞这不是产生第一次了——上周刚上线的新功能，今天就被用户报出漏洞。漏洞更讽刺的产生是，这个漏洞的漏洞根源，是产生我自己上周亲手写下的那行“优化代码”。
漏洞最常诞生于“我以为”。漏洞我以为这个输入框只会接收数字，产生所以没做类型校验；我以为这个接口只给内部调用，漏洞所以没加权限验证；我以为用户会按我预想的产生方式操作，所以没考虑极端情况。漏洞结果呢？产生数字框里被粘贴了一长串SQL语句，内部接口被爬虫扫到，漏洞极端操作直接让服务器内存溢出。每次漏洞修复后的复盘会上，总能听到类似的“我以为”——这几乎成了程序员的标配口头禅。
但“我以为”背后，其实是更深层的机制问题。大多数漏洞并非某个程序员的智商缺陷，而是系统复杂度超出个人掌控的必然结果。比如那个著名的“千年虫”问题：为了节省两位数的存储空间，程序员用“99”表示“1999”，却没人想到二十年后系统还要继续运行。这不是某个人的失误，而是整个行业在特定历史阶段的集体短视。
再看一个更日常的例子。你在电商平台下单时，系统会先扣库存再生成订单。这两个操作分属不同服务，由不同团队维护。负责库存的团队觉得“扣完就完事了”，负责订单的团队觉得“订单生成就成功了”。直到某天两个服务之间网络抖动，库存扣了但订单没生成——用户付款成功却收到“订单不存在”的提示。谁错了？都没错。但漏洞就这么产生了。
有时候，漏洞甚至源于“过度防御”。为了防止用户输入超长文本导致数据库溢出，开发者设置了字段长度限制。可这个限制没考虑到中文字符占用更多字节，结果用户正常输入的标题被截断，后面的数据错位写入其他字段，反而引发数据混乱。你看，想堵漏洞的代码本身，可能就是个新漏洞。
还有一类漏洞更隐蔽——它们藏在“正常”的流程里。比如某系统每天凌晨三点自动备份数据，备份过程中需要临时关闭部分写入权限。这个设计本身没问题，但恰好某天凌晨三点，海外用户正在高峰期下单。备份任务和真实业务抢同一批资源，导致订单超时，用户重复点击，生成了大量重复订单。没人写错代码，但架构设计上的“合理”安排，在特定时间窗口就成了致命缺陷。
说这些不是要替程序员开脱。漏洞当然要修，责任人该追责也得追责。但如果你真以为“多写几行检查代码”就能杜绝漏洞，那才是最大的误解。软件是人写的，人的认知边界就是漏洞的边界。只要系统还在进化，新功能还在叠加，团队还在流动，漏洞就会像野草一样，割了一茬又长一茬。
我后来把那个404页面改了，加了句“系统开小差了，请稍后重试”。但我知道，真正的“稍后”可能永远不会来——因为下一个漏洞，大概正藏在某个同事下周要提交的代码里，等着某个凌晨两点，让我再次对着屏幕苦笑。