每一个IT从业者几乎都曾为了救火而仓促拼凑过某种临时修复方案并安慰自己“以后有空再重构”。然而那个“以后”通常永远不会到来。这些应付眼前的临时补丁最终会在生产环境中雷打不动地运行许多年熬过版本迭代送走几波团队成员甚至反客为主沦为产品不可分割的核心功能。在上世纪90年代许多应用程序检测操作系统版本的方法极其粗暴它们直接在系统名称字符串中检索数字“9”以此来判定系统是 Windows95还是98。正因如此如果微软当年真的发布了“Windows9”这些老旧程序就会直接把它误判为 Windows95/98导致灾难性的后果。尽管微软官方曾辟谣称跳过Windows9是出于市场营销考量但人们在很多开源代码库中确实找到了大量基于系统名称进行兼容性检查的Java代码。这种“草率的代码补丁”在当年大行其道。讽刺的是恰恰是为了迁就这些临时补丁我们才永远错过了Windows9而Windows10则顺理成章地成为了全球操作系统的全新标杆。另一个将“权宜之计改造成永久特征”的殿堂级案例是微软Excel中“不存在的 1900年闰年”。如果你在Excel中输入1900年2月29日程序会判定这是一个合法日期。在现实公历中这一天根本不存在1900年是平年并非闰年。这并不是一个Bug而是开发团队的“蓄意之举”。这要追溯到当年为了兼容行业老大哥Lotus 1-2-3 电子表格程序。Lotus的开发者当年为了简化日期计算强行将1900年当成了闰年。微软在开发Excel时为了抢占市场采取了全盘复制其计算逻辑的策略连同这个Bug也一并继承了过来。这样用户就能毫无违和感地将旧表格从Lotus迁移到Excel中。随着岁月的流逝这个原本为了兼容而打的“临时补丁”最终变成了尾大不掉的历史包袱。从技术层面来看Excel内部的日期计算其实存在一天的偏差。微软对此心知肚明但也明确表示过修复这个Bug的成本已经高到无法承受。任何试图修正它的尝试都会导致全球数以亿计的历史文件出现日期错位、公式失效整个软件生态的兼容性将彻底崩溃。最终微软选择维持现状。这个Bug带来的唯一影响只是在计算1900年3月1日之前的日期对应的星期几时会出错。但几乎没人会去计算那个年代的星期于是这个技术奇观便一直保留至今而“1900年2月29日”也成了科技界经久不衰的一个烂梗。这就是传说中的“临时补丁”……纸飞机 Telegram 迎来重大更新正式上线“社区”功能谷歌将大幅缩减旧版本 Android 的安全补丁移植范围