微软 40 年不敢修复的 Excel 历史级 Bug：源于竞品、写入行业标准，至今无人敢动

步步糕升

前言


Excel 被誉为办公软件之王，网友调侃它 “除了生孩子什么都能做”，发展至今已经走过四十余年。但这款全球几十亿人每天使用的工具，藏着一个从诞生延续至今、微软明知错误却坚决不修复的底层 Bug。
随便做一个简单测试：在 Excel 单元格输入6/2，单元格会识别为 6 月 2 日，再输入公式=A1+1，得出的数字会比真实日期序列号多 1。这个微小偏差，根源是 1900 年被错误判定为闰年，而微软为了兼容四十年前的竞品，选择永久保留这个缺陷，甚至把它写入 OOXML 官方文档，WPS 也同步继承了这套逻辑。

一、直观现象：一个简单加法就能暴露日期偏移 Bug


打开任意 Windows 版 Excel，复现测试步骤：

• 单元格输入6/2，软件自动识别为日期「当年 6 月 2 日」；
• 输入公式=A1+1，把日期转为序列号；
• 换算真实公历天数会发现，输出数字比标准日期多 1 天。
  

底层根源：Excel 日期系统凭空多出了1900 年 2 月 29 日这个不存在的日期。
按照格里高利闰年规则：能被 100 整除但不能被 400 整除的年份是平年，1900 无法被 400 整除，当年 2 月只有 28 天，不存在 29 日。但 Excel 拖拽日期时，1900-02-28 后会直接跳到 1900-02-29，再到 3 月 1 日，凭空多出一天，所有 1900 年 3 月 1 日之后的日期序列号全部偏移 1 位。

二、Bug 溯源：来自 Lotus 1-2-3 的偷懒设计


1. 80 年代电子表格霸主 Lotus 1-2-3


1983 年 Lotus 1-2-3 是 DOS 时代垄断级表格软件，几乎所有企业财务都在用。当年硬件算力有限，开发团队为简化闰年计算逻辑，直接简化规则：默认每 4 年一闰，无视 “百年不闰、四百年再闰”，强行把 1900 标记为闰年Microsoft ...。
当年绝大多数用户只处理现代财务日期，几乎不会用到 1900 年前后的数据，这个缺陷暂时没有暴露。

2. Excel 为抢占市场主动 “复刻错误”


1985 年 Excel 初代仅支持 Mac 系统，为避开冲突，只允许 1994 年后日期；1987 年 Windows 版 Excel 2.0 上线，面对 Lotus 绝对垄断的市场，微软核心策略是全文件兼容，保证用户可以直接把 Lotus 表格导入 Excel，公式、日期完全不出错。
如果微软修正闰年逻辑，所有 Lotus 表格导入后日期会全部差 1 天，企业财务报表、账目全部失效，客户会直接放弃 Excel。权衡之下，微软主动复刻了 Lotus 1-2-3 的闰年 Bug，沿用同一套日期序列号体系Microsoft ...。

3. Excel 两套日期基准的双重矛盾


Excel 官方文档存在两处前后矛盾的日期基准描述：

• 文字标注：序列号 1=1899 年 12 月 31 日；
• 实际程序逻辑：序列号 1=1900 年 1 月 1 日，序列号 60 对应不存在的 1900-02-29；
  本质是为适配 Lotus 遗留体系强行妥协，两套基准混用形成文档冲突，微软后续仅在部分函数说明中微调文字，底层逻辑从未改动。
  

三、为什么时隔 40 年，微软依旧不敢修复？


1. 全球海量存量文件会集体出错


如果官方修正 1900 闰年判定：

• 所有 1900 年 3 月 1 日之后的日期，序列号全部减 1，表格日期整体前移一天；
• 财务报表、考勤、合同工期、库存统计、老旧企业系统全部出现一天误差；
• WEEKDAY、EDATE、DATEDIF 等日期函数全部返回错误结果，上亿份历史表格彻底失效Microsoft ...。
  

2. 行业标准已固化，上下游全部适配该 Bug


这套错误日期逻辑被写入OOXML（XLSX 官方标准），规范明确要求表格软件必须兼容 1900 假闰年，所有表格开发工具、国产 WPS、在线表格均同步适配这套规则。一旦微软单方面修复，生成的文件会和其他软件日期对不上，跨平台数据完全无法互通。

3. 日常使用影响极小，修复成本无限大


现代办公、财务、统计几乎不会用到 1900 年之前的历史日期，绝大多数用户一辈子碰不到这个缺陷；但修复带来的全行业适配、企业历史数据重构成本，是微软、全球企业都无法承受的，因此官方选择永久保留，把 Bug 变成 “标准特性”。

四、各表格软件差异化表现

• Windows Excel / WPS 表格：完全继承 Lotus 逻辑，识别 1900-02-29，日期序列号偏移 1 天，日常财务计算通用；
• Excel for Mac（旧 1904 日期系统）：早年 Mac 版单独使用 1904 基准，无 1900 闰年问题，新版可手动切换两套日期体系；
• Google Sheets：修正了 1900 闰年错误，无虚拟 2 月 29 日，和 Excel 互导 1900 年初日期会出现 1 天差值。
  

五、普通用户避坑实操方案

• 处理 1900 年前历史数据
  不要直接用日期格式，全部存储为纯文本，或使用 Power Query 单独处理历史时间，规避序列号偏移；
• 跨平台文件核对
  Excel 与 Google Sheets 互相传输百年前历史表格时，手动校验日期差值，现代日期（1900 年后三月起）日常使用无感知；
• Mac 用户切换日期系统
  文件→选项→高级，勾选「使用 1904 日期系统」，即可消除 1900 闰年带来的偏移，但文件传给 Windows 端会产生新偏差，仅本地存档使用。
  

六、结语


这个延续 40 年的 ExcelBug，不是技术失误，而是商业兼容下的历史妥协。当年为争夺市场复刻竞品缺陷，如今行业标准、亿万存量文件、企业系统全部绑定这套错误逻辑，微软再强大也无法单方面推翻。
很多程序员把它称为行业最大 “技术债”，一个小小的闰年判定错误，折射出软件行业最现实的规则：兼容性永远优先于完美逻辑，一旦标准形成，哪怕是错误，也会持续运行数十年。