摘要

工程师先给了“可以上线”的答案

2017 年 2 月那封邮件不是宣布 W3C 已完成正式标准。它说的是更锋利的一件事：初版接口与格式的设计已走到必须靠实现经验和实际使用继续推进的阶段。浏览器预览期结束，厂商可以默认启用。四个独立浏览器阵营同时接受这个目标，比任何单方演示都更能改变开发者的选择。

同一封信也划下未来的负债。新功能必须与初版保持兼容。只要网站开始发送按该格式编译的模块，随意改二进制结构或 API 就会伤到已经投入运行的程序。这是社区组与浏览器厂商共同承担的部署承诺，不是先写一页纪要、再看有没有人使用的空头授权。

归档原文当时已列出 JavaScript API、二进制格式和参考解释器，还把成立 W3C 工作组、为初版制定正式规范列为下一步。所以“W3C 首份公开草案尚未出现”并不等于“没有设计文件”。一个是社区组准备交给实现者检验的 MVP；另一个是经过正式标准程序发布的文件。二者的权威来源不同。

运行中的四款浏览器越过了计划表

Mozilla 11 月的记录指出，Safari 和 Edge 也已发布支持，加入先前的 Firefox 与 Chrome。这证明四款产品进入发布状态，不证明所有设备都已更新，也不是用户覆盖率统计。对要把计算密集的程序编译进网页的开发者而言，已有多个实际浏览器能运行同一初版格式，便足以改变试验和部署的时间表。

W3C 2017 年工作组章程预计当年第四季度有首份公开草案，2018 年第二季度形成首版推荐标准。实际出版记录是：2018 年 2 月首份草案，2019 年 7 月候选推荐版本，2019 年 12 月正式推荐。计划时间落后了。文件没有给出单一拖延原因，写成某次会议卡住了整个互联网，反而会冲淡真正可核查的冲突：代码的部署时钟与机构的文件时钟从来没有重合。

正式标准负责把边界写清楚

W3C 2019 年公告一次发布三份推荐标准：核心规范定义虚拟机与代码格式，JavaScript 接口定义函数调用和传值，Web API 定义怎样请求并执行资源。能读懂一个二进制模块，不等于能在网页里稳定加载它、与宿主环境交互并在不同实现中得到相同结果。正式标准的工作正是把这些接口从“大家大体这样做”变成能逐项检验的公共契约。

章程还要求测试集、实现报告、公开讨论以及跨工作组审查。浏览器提前上线，不会让这些工作变得多余；标准后来完成，也不会倒过来成为 2017 年发布的原因。WebAssembly 这段历史的顺序很清楚：社区组锁定足够能运行的初版，厂商让它在产品里工作，W3C 再把规则和责任写成正式文本。谁先动手、谁后盖章，都在原始记录里。