世界上最长寿的，莫过于那些“临时补丁”…

每一个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 的安全补丁移植范围