漏洞检讨书

凌晨两点十七分，漏洞我盯着屏幕上那个刺眼的检讨红叉，系统提示“内存访问违规”。漏洞这不是检讨第一次了。上周三下午三点，漏洞生产环境崩溃，检讨三百个用户同时断连，漏洞客服电话被打爆。检讨我写的漏洞代码，我埋的检讨雷。

追溯起来，漏洞问题出在三个月前那次重构。检讨当时觉得旧模块太臃肿，漏洞想当然地“优化”了内存管理逻辑。检讨我甚至没跑完整测试用例——只测了主流程，漏洞就匆匆提交。那种“应该没问题吧”的侥幸心理，现在想想，真是愚蠢得可笑。指针悬空、内存泄漏、边界条件没处理，教科书上反复强调的坑，我一个不落全踩了。

更讽刺的是，我早就知道问题可能在哪。代码评审时，同事老张提过一句：“这个释放逻辑是不是有点激进？”我当时怎么回的？“没事，我测过了。”测过了？就测了happy path就叫测过了？老张没再说话，我也没当回事。现在回头看，那大概是我职业生涯里最贵的一句话。

修复本身不难，难的是承认自己错了。昨天开会，我坐在工位上，看着监控曲线从红色慢慢变绿，心跳才跟着恢复正常。项目经理没骂我，只说了句：“下次先跑回归。”就这么轻飘飘一句话，比骂我一顿还难受。因为我知道，他是在给我留面子，也是在提醒我——信任这种东西，消耗起来很快，重建起来很慢。

写代码这行，最怕的不是技术难题，是那种“我懂了”的错觉。你觉得自己理解了系统，其实只是理解了你写的那部分。真实环境里，内存、并发、第三方依赖、用户行为，哪个都能让你的“完美逻辑”碎成渣。我犯的错，本质上不是技术失误，是态度失误——把“能跑”当成了“正确”，把“差不多”当成了“完成”。

现在我的工位上贴着一张便利贴，写着“先怀疑自己，再怀疑编译器”。听起来挺鸡汤，但真管用。每次想跳过测试直接提交，我就看一眼那张纸。代码不会骗人，骗人的只有自己给自己找的借口。这次漏洞，就当是交学费了。学费挺贵，但希望以后能长点记性。