凌晨两点，漏洞原因我盯着屏幕上的漏洞原因报错日志，咖啡杯沿留下一圈干涸的漏洞原因褐色痕迹。那段代码我写了三天，漏洞原因逻辑反复推敲过，漏洞原因单元测试全绿。漏洞原因可上线后，漏洞原因用户数据像是漏洞原因被风吹散的纸片，一条条凭空消失。漏洞原因 问题出在缓存。漏洞原因 Redis里的漏洞原因过期时间设置成了`-1`，意味着永不过期。漏洞原因但服务器重启时，漏洞原因内存被清空，漏洞原因而数据库里的漏洞原因主键却还在按旧序列递增。新写入的数据ID从1重新开始，覆盖了旧记录。这就像你给图书馆每本书贴了同样的编号，再往书架上乱插一遍，谁也找不到谁。 我翻出三个月前的提交记录——那天凌晨我改了个配置项，把`expire_time`从`86400`改成了`-1`，注释写着"测试用，稍后改回"。稍后就是三个月。没人会在测试环境里跑这么久，可偏偏这台服务器被误加了生产环境的负载均衡。 这不是技术失误，是流程漏洞。 代码评审的时候，负责审查的同事只看了核心业务逻辑，对这种"无关紧要"的配置项一扫而过。测试环境没人盯着过期时间，因为测试数据量小，重启频率高，根本暴露不了冲突。生产环境的数据量是测试的千倍，索引一乱，查询直接全表扫描，超时、熔断、雪崩，连环反应。 我突然想起上个月隔壁组的故障。他们对外接口突然返回乱码，排查了两天，最后发现是字符集配置不一致——数据库用的是utf8mb4，但连接池参数里写死了latin1。当时大家笑称这是"最蠢的bug"，可仔细想想，和我的Redis过期时间有什么本质区别？都是某个环境里顺手改的配置，没人记录，没人同步，像定时炸弹一样埋着。 现在市面上流行各种"根因分析法"，什么5Why、鱼骨图、故障树。真到了现场，你会发现大部分故障根本用不上这些工具。就是一个人偷懒，一群人没检查，一个环节被跳过，然后系统在某个不凑巧的时刻把隐患变成事故。 我把这段经历写进团队wiki，标题叫《别信注释，信测试》。但我知道下个月还会有人犯类似的错，因为人脑天生会忽略"暂时"和"永久"的边界。修复这个漏洞不需要更聪明的代码，只需要在评审清单里加一条：任何改动，无论多小，都要写清楚影响范围。哪怕只是改个数字。 窗外天亮了，我盯着那段被修复的代码——`expire_time`改回`86400`，旁边加了一行注释：别改成-1，除非你想在凌晨三点被电话叫醒。这次没人会忽略了。