摘要

  • W3C 在 2026 年 8 月 20 日批准 WebAssembly 工作组新章程，授权期至 2028 年 8 月 27 日；既有三项核心规范将修订，并新增 Code Metadata 与三项 Legacy Extensions 工作。
  • Component Model 在章程中是有条件的成果：WebAssembly 社区组必须先按自身流程把提案推进至第四阶段。
  • 截至本文截点，固定版本的公开提案表仍把 Component Model 列在第一阶段。该编号是制度状态，不是否定实现、用户或工程价值的评分。
  • Component Model 仓库列出 WASI Developer Preview 0.2.0、0.3.0 和 0.3.1，并说明启用的功能会由生产者与消费者工具保持稳定，以支持浏览器外生产使用并收集反馈。
  • 第四阶段要求实现、测试、完整规范、参考解释器和社区组共识等证据；完成移交后，工作组还须形成自己的共识并走完 W3C 标准程序。
  • 最小的治理补丁是一份“双钥匙晋级档案”：先把精确提案版本、逐项证据与社区组决定接起来，再单独记录工作组接收决定和 W3C 发布状态。

章程批准的是一条路

W3C 的批准通知很短，真正划定权力边界的是章程。它从 2026 年 8 月 20 日生效，到 2028 年 8 月 27 日结束，列明主席、团队联系人、范围、成果和决策规则。WebAssembly Core Specification、JavaScript Interface 和 Web API 的新版本属于工作组可直接开展的工作；Code Metadata Specification 以及用于隔离已弃用但可能仍被使用的三项 Legacy Extensions 规范也被纳入。

Component Model 的措辞不同。工作组“计划交付”该规范，但前提是它先在 WebAssembly 社区组流程中达到第四阶段。这里既没有宣布拒绝，也没有完成接纳。章程只预先说明：条件满足后，哪个正式机构有权接手。

这项条件并非 2026 年突然出现。2023 年章程已经以第四阶段作为 Component Model 进入工作组的门槛。新章程延续了同一制度设计。三年孵化可能积累大量代码与经验，却不会自动替代一次尚未公开登记的阶段决定。

因此，“出现在 W3C 章程里”与“已成为 W3C 标准”之间至少隔着两次可归属的行动：社区组确认提案达到移交门槛，工作组再决定是否按 W3C 轨道接收和推进。把路线图当成抵达证明，会让授权先于证据。

公共登记表的数字仍是一

WebAssembly proposals 仓库提供了公开的提案状态表。本文固定到 8 月 10 日的提交，以便任何读者重现当时记录。表内有处于第五、第四、第三、第二和第一阶段的不同提案，Component Model 位于第一阶段一栏。

这个记录比从会议热度、厂商宣传或代码数量推断状态更可靠，但它能证明的范围也必须收窄。它没有说 Component Model 无人使用、已经放弃、不适合生产或缺乏重要性；它只说明，按这套公开流程，尚未登记为更高阶段。

同样，8 月 10 日之后没有出现表格变更，并不能证明没有讨论、尚未合并的修改或尚未发布的决定。本文能复核的是截点前固定版本。未来若发生晋级，正确做法是新增带日期、对象和依据的状态记录，而不是倒推第一阶段从来没有治理意义。

阶段编号也不是成绩。第一阶段表示社区组认为提案在范围内、方向看起来可行，值得由推动者继续形成设计与共识。它不统计融资、下载量、规范页数、部署数量或行业关注度。把“第一”读成“刚刚开始”，会抹掉已经发生的工程；把大量工程读成“自然已经第四”，则会抹掉仍需完成的制度动作。

第四阶段是一场有证据的移交

公开的阶段流程把成熟度与权力分开安排。每次晋级需要进入社区组会议议程，由社区组判断下一阶段条件是否满足。第二阶段要求精确、完整的方案概述和相当程度的共识；第三阶段加入测试套件与实现工作；第四阶段的要求显著提高。

在适用情况下，至少两个 Web 虚拟机要实现该功能并通过测试，至少一个工具链要实现它；规范和参考解释器须完整，解释器须通过测试；社区组还要同时对功能本身与规范完整性形成共识。条件中的“适用”也不应成为空白豁免。若某项无需满足，记录应说明由谁、基于什么理由作出判断。

第四阶段完成后，提案才被完整移交工作组。工作组并非盖章窗口。它要检查边缘情况，确认自己的共识并履行 W3C 标准化流程；若需要重大变更，工作会返回社区组。第五阶段则要等工作组认为功能完成，随后合并并进入 W3C 快照。

这套安排阻止两个捷径。工作组不能仅凭章程预留位置，就把早期方案称为成熟规范；活跃的社区组也不能让一次内部阶段决定直接等同于 W3C 推荐标准。实现者为两边提供关键证据，但发布代码并不会把任何一把制度钥匙转动。

第一阶段可以拥有生产反馈

最有力的反证来自 Component Model 自己的仓库。它包含设计材料、二进制与文本格式、链接和 ABI 文档以及不断扩充的测试。里程碑列出 WASI Developer Preview 0.2.0、0.3.0 与 0.3.1：0.2.0 是首个基于 Component Model 的预览，0.3.0 增加原生并发，0.3.1 又加入新的类型和注解。

仓库明确表示，预览版启用的功能会由生产者和消费者工具保持稳定，使其能够在浏览器外的生产环境使用，同时收集真实反馈。这足以否定“第一阶段等于没有东西”的懒惰解释。团队可以在正式标准化前部署一个边界明确的预览面，作出兼容性承诺并学习运行结果。

同一份 README 也说，正式规范与参考解释器将在未来补充。这正好解释了工程成熟和制度阶段为什么可能不同步：生态可以稳定某一使用剖面，却尚未完成第四阶段要求的全部工件、实现广度和共识记录。

反过来的误读更危险。生产使用不会悄悄完成社区组表决、写完参考解释器、把提案移交工作组或发布 W3C Recommendation。运行代码是证据，而且往往是最有价值的证据；它不是一份自动授权书。

社区组与工作组不是大小之分

W3C 把社区组定义为开放、免费的早期协作场所。任何拥有 W3C 账户、接受 Community Contributor License Agreement 的人都可加入 WebAssembly 社区组。其公共页面同时提醒，社区组由社区自行运行，其成果不必然代表 W3C 会员或工作人员的观点。

W3C 对文档状态也很清楚：社区组报告不是标准轨道文档，也不是 W3C 标准。它们可以成为正式流程的输入。知识产权安排和既有工作组章程能够降低转入成本，但“能够转入”仍不等于“已经转入”。

这条边界保护双方。社区组可以快速迭代，吸收非会员贡献者，在完整 Recommendation Track 之前验证设计；工作组可以接收成熟成果，同时承担独立共识、横向审查、专利政策和发布义务。参与范围扩大了判断材料，却不能自动制造机构授权。

状态压缩会把成本藏起来

状态词会流出标准会议。工具厂商可能宣布支持“Component Model”，却不标明预览版本与仓库提交；采购方听到“写进 W3C 章程”，可能误以为已完成 Recommendation 级审查；工程师看到第一阶段，可能错过已有工具承诺稳定的生产剖面；贡献者也可能在错误的机构等待决定。

这些并非纯粹的措辞争执。ABI、链接或资源生命周期一旦大规模部署，后续变更会产生昂贵迁移。兼容性成本会对正式决策形成压力，即使新证据支持另一种设计。这个压力可能完全合理，但它应作为证据和转移成本出现在档案中，不应悄悄取代授权。

建立“双钥匙晋级档案”

不需要新设一个最高委员会。需要的是把现有公共状态接起来的薄记录。

社区组一侧应从不可变的提案版本开始，列出当前阶段、最近一次阶段决定的日期与记录、申请阶段的进入条件，并让每项条件链接到证据：具体 Web VM、精确测试套件版本和结果、工具链实现、正式规范、参考解释器以及未解决例外。若只推进一个有限子集，必须明确列出；同名预览中的其他功能不能被品牌名称顺带移交。

决定条目应记录公开议程、决定方法、结果和正式异议，而不能把到场人数包装成全体利益相关者同意。它应冻结被表决的对象，避免随后修改的仓库内容被倒填进旧决定。

第二部分从工作组接收开始，记录接收版本、CfC 或其他决定、被退回孵化的问题、横向审查、专利政策状态、实现报告和 W3C 发布状态。重大变更若导致返回社区组，应产生新状态而非改写原移交记录。

这份档案无需公开私人法律意见、商业路线图或每句会议发言。它只需公开解释两把钥匙为何转动所必需的最小制度与证据状态。

截至 8 月 31 日能确认什么

W3C 已批准现行 WebAssembly 工作组章程。工作组可以处理无条件成果，也有权在指定条件满足后接收 Component Model。公开提案表仍将其列为第一阶段；项目仓库记录了实质性的开发者预览工作和浏览器外有限的生产使用。

已核对材料不能证明社区组拒绝过第四阶段申请，不能证明 W3C 延误，也不能证明某个实现者绕过流程。它不支持不兼容、不安全、厂商俘获或专利缺陷等结论。它同样不能证明 Component Model 已是 W3C Recommendation。

最准确的状态没有戏剧性，却更有用：技术是真实的，正式晋级尚未完成，新章程保留了两者之间的路径。下一次状态变化应留下可验证的决定收据。

来源

  1. W3C：WebAssembly 工作组章程批准通知
  2. W3C：2026 年 8 月 20 日生效的 WebAssembly 工作组章程
  3. WebAssembly：固定于 2026 年 8 月 10 日的提案登记表
  4. WebAssembly：阶段晋级流程
  5. WebAssembly：Component Model 仓库里程碑状态
  6. W3C：WebAssembly 社区组
  7. W3C：社区组与商业组常见问题
  8. W3C：发布的文档类型
  9. Lu Heng：The Multi-Stakeholder Mirage