AI 摘要：本文是 Node.js 核心贡献者 Joyee Cheung 关于 require(esm) 功能实现细节的深度解析。文章聚焦于该功能在落地过程中，为兼容现有生态系统而必须解决的几个关键互操作性问题：包括如何处理“伪 ESM (faux-ESM)”包的 __esModule 标记、如何通过特殊导出 "module.exports" 支持非对象字面量的 CommonJS 导出、如何引入 "module-sync" 导出条件来支持双包 (dual package) 的平滑迁移，以及如何通过 process.getBuiltinModule() 避免不必要的顶层 await。文章揭示了看似简单的功能背后，为保持生态稳定性和性能所付出的复杂工程努力，并强调了社区协作在推动此类停滞计划中的关键作用。

1. 伪 ESM (Faux-ESM) 的兼容性挑战
• 问题根源：许多为浏览器打包的库在 Node.js 端发布的是转译后的 CommonJS 代码（即“伪 ESM”），它们依赖 __esModule 标记来模拟 ESM 的命名空间行为。
• 兼容性断裂：如果这些包直接迁移到纯 ESM，其现有的转译后消费者通过 require() 加载时将因缺少 __esModule 标记而中断。
• 解决方案评估与选择：在无法直接修改不可变的模块命名空间对象的前提下，评估了多种方案（对象拷贝、Proxy、原型继承、ESM 门面模块），最终选择了通过创建一个内部 ESM 门面模块（使用 export * from 并额外导出 __esModule）的方案，以在保证正确性（保持实时绑定、身份和可枚举性）的同时，将性能开销降至最低（约 2-4%）。

2. CommonJS 特殊导出模式的兼容
• 导出形状不匹配：CommonJS 允许 module.exports 被重新赋值为任何值（如一个类），而 ESM 的默认导出位于命名空间的 default 属性下，这导致迁移后 CommonJS 消费者无法正确获取导出值。
• 特殊导出方案：引入了名为 "module.exports" 的字符串字面量特殊导出。ESM 模块可以通过 export { Klass as "module.exports" } 来显式指定 require(esm) 应返回的值，从而无缝兼容旧的 CommonJS 消费者，而无需改变 ESM 消费者的导入方式。

3. 双包 (Dual Package) 的迁移路径
• 条件导出的演进：为了在支持旧版 Node.js（仅 CommonJS）的同时，为新版 Node.js 提供 ESM，包作者曾使用 "node" 条件指向 CommonJS。
• 新条件的引入：由于生态中已有的 "module" 条件常指向无法在 Node.js 直接运行的打包后代码，Node.js 引入了新的 "module-sync" 条件，专门用于指向可在 Node.js 中同步加载的 ESM 源文件，作为向纯 ESM 包过渡的临时方案。

4. 同步内置模块检测
• 问题背景：在 ESM 中动态检测内置模块（如 node:os ）过去只能通过异步的 import() 实现，这迫使代码使用顶层 await。
• 同步 API 的引入：为解决此问题并方便工具链（如 TypeScript），Node.js 引入了 process.getBuiltinModule() 这个同步 API，允许在 ESM 中同步获取内置模块引用，减少了对顶层 await 的依赖。

5. 底层实现与同步化
• 概念模型：require(esm) 的简化逻辑是同步地获取、链接、评估 ESM 模块，然后返回其命名空间。
• 同步化重构：实际的挑战在于与异步 import 共享的模块缓存和加载流程可能引发竞态条件。随着 Node.js 生态对同步模块加载的坚定依赖，原先为未来异步扩展设计的加载器例程被简化为完全同步，这既消除了竞态，也移除了不必要的异步开销。

6. 模块评估的可重入性保障
• 规范限制：ECMAScript 规范规定，一个正在评估中的 ESM 模块不能被再次评估。
• 循环依赖处理：当模块依赖循环跨越 ESM 和 CommonJS 边界时，Node.js 通过检测并抛出 ERR_REQUIRE_CYCLE_MODULE 错误来防止违规的重入评估。未来的 “Deferring Module Evaluation” 提案可能允许安全地跳过同步重入评估，从而支持此类循环。