Firefox 148 关掉的，不是 asm.js 兼容性。
Mozilla 做的是另一件事：SpiderMonkey 里那条专门给 asm.js 准备的优化路径，默认禁用了。asm.js 内容还会跑，因为它本来就是 JavaScript 子集。只是以后不再走专门编译通道，而是回到普通 JIT 路径。
这件事最容易被误读成“Firefox 不支持 asm.js 了”。不是。
真正的信号在后半句：Mozilla 计划未来移除相关代码，并建议还在发布 asm.js 内容的维护者迁到 WebAssembly。旧通道还没塌，但路牌已经拆了。
Firefox 148 关了什么，谁该动手
| 问题 | 现在的变化 | 直接影响 |
|---|---|---|
| asm.js 专用优化 | Firefox 148 默认禁用 | 不再走 SpiderMonkey 的专门快路径 |
| JavaScript 兼容性 | 没有删除 | 现有 asm.js 内容仍按普通 JS 执行 |
| 后续计划 | Mozilla 计划移除相关代码 | 浏览器内核少维护一条旧路径 |
| 迁移建议 | 转向 WebAssembly | Mozilla 明确提到执行更快、二进制体积更小 |
普通用户大概率无感。网页不会因为这件事突然白屏。
真正该看代码仓库的人，是还在维护 asm.js / 老 Emscripten 输出的开发者。动作很简单，但不一定轻松：确认当前构建产物是不是还在发 asm.js；如果是，评估能不能重新编译到 WebAssembly；迁移后再测启动、执行和包体，不要只凭“Wasm 更好”四个字上线。
这里有个现实约束：老项目最难的往往不是改目标格式，而是构建链已经锈住。依赖锁死、脚本没人敢碰、发布流程没人记得，这些都比技术路线本身更烦。
所以这不是一张“立刻重构”的罚单。更像一封到期提醒：如果项目还有人维护，就别再把 asm.js 当长期方案。
asm.js 当年赢在一件事：没有绕开 Web
asm.js 是 2013 年随 Firefox 22 推出的。
那时浏览器面对一个硬问题：Web 能不能跑接近原生性能的 C/C++ 代码？Google 曾推 NaCl、PNaCl 这类路线，更像给浏览器旁边再开一条原生通道。Mozilla 选了另一条路：仍然站在标准 JavaScript 里，挑出一个更容易被引擎识别和优化的子集。
这就是 asm.js 的历史位置。
它不是今天这种“遗留格式”的开端，而是高性能 Web 的前史。Unity、Unreal 等大型 C/C++ 代码库上 Web，asm.js 起过实打实的支撑作用。当年的演示不是炫技，它在证明浏览器不只会跑文档、表单和脚本小玩具。
后来 WebAssembly 接棒。Firefox 52 开始支持 Wasm。到今天，性能路径、工具链、生态投入、安全维护的重心，都已经转到 WebAssembly。
asm.js 和 WebAssembly 的关系，不像两个并列竞品。更像临时栈桥和正式桥梁。
栈桥的价值是让车先过河。正式桥修好后，栈桥继续占着人力、检查表和风险清单，就变成成本。
功臣也会变成维护负债
我更在意 Mozilla 给出的关闭理由：使用已经迁移，继续维护成本高，虚拟机里多一条路径就多一块攻击面。
这句话不漂亮，但很真实。
浏览器内核不是纪念馆。每留一条专用路径，都要有人读、有人测、有人修。还要在安全边界里继续承担风险。对平台来说，兼容不是免费美德，是长期税单。
《道德经》里讲“功成身退”。放在 asm.js 上，不玄。
它的功，是用标准 Web 技术打开了近原生性能的大门；它的退，是因为 WebAssembly 已经接走了门框、门锁和维护预算。
这件事也提醒开发者，不要把过渡方案当祖产。很多技术最危险的时刻，不是没人用，而是还有少量项目在用，却没人愿意为它继续付维护成本。平台方迟早会算账。
接下来最该看两件事。
一是 Mozilla 什么时候真正删除相关代码。默认禁用还留回旋余地，移除代码才是账本清零。
二是老项目迁移时暴露出多少构建债。asm.js 内容还能跑，所以短期不会逼出大面积故障；但还在依赖这条路径的项目，会越来越像站在旧码头等船。
这不是 Firefox 放弃高性能 Web。恰恰相反，是高性能 Web 不再需要 asm.js 证明自己。
旧通道关门，舞台没塌。只是主角已经换成 WebAssembly。