JS模块化详解：ES Module与CommonJS区别

ES Module（ESM）与CommonJS（CJS）绝非语法糖式的替代关系，而是底层设计哲学截然不同的两套模块系统：ESM基于静态分析、顶层声明、实时绑定与异步加载，强调构建时优化与严格规范；CJS则依赖动态执行、同步加载、值拷贝与运行时灵活性。二者在导入导出语法、缓存机制、路径解析、循环依赖行为、this绑定乃至跨环境兼容性上全面不兼容——混用必报错，误用易埋坑。理解这些根本差异，是写出可维护、可优化、跨平台稳健的JavaScript模块化代码的前提。

ES Module（ESM）和CommonJS（CJS）不是“两种可随意互换的写法”，而是两套底层机制完全不同的模块系统——它们在加载时机、语法约束、变量绑定方式、缓存行为上都不可兼容。你在 Node.js 里混用 import 和 require，或在浏览器中直接 require('./utils.js')，都会立刻报错。

为什么 import 不能写在 if 里？——静态分析是 ESM 的硬性前提

ESM 要求所有 import 和 export 必须出现在模块顶层，这是为了支持编译时依赖分析（比如 Webpack 的 Tree Shaking 或 Vite 的预构建）。一旦你把它放进条件分支，工具就无法提前知道这个模块到底依赖谁，整个优化链路就断了。

• import 是声明式语法，不是函数调用，不能动态执行
• 想实现“按需加载”？必须用 import()（注意括号），它返回 Promise，是运行时异步操作
• 错误写法：

  if (condition) {
    import { foo } from './module.js'; // ❌ SyntaxError: Cannot use import statement inside a module
  }

• 正确替代：

  if (condition) {
    import('./module.js').then(({ foo }) => foo());
  }

require('./a') 和 import('./a') 看似相似，实则完全两类东西

require 是 CommonJS 的同步运行时 API；import() 是 ESM 的异步运行时函数——前者会立即阻塞执行、读取并执行模块；后者只是发起一个异步加载请求，不阻塞主线程。

• require 返回的是模块导出对象的“值拷贝”（如 exports.count = 1，后续改 count 不影响已导入的值）
• import() 返回的是模块的实时引用（修改导出变量，所有导入处都能看到变化）
• Node.js 中，require 支持路径省略后缀、自动查找 index.js、支持 JSON 文件；import() 严格要求完整路径和扩展名（./utils.js ✅，./utils ❌）
• 浏览器中 require 根本不存在，必须用打包工具转译或彻底迁移到 ESM

Node.js 里同时存在两种模块，但它们不共享缓存和 this 绑定

即使你用 "type": "module" 声明项目为 ESM，也不能在同一个文件里混用 import 和 require；更关键的是，CJS 模块被 ESM import 后，其 module.exports 会被包装成默认导出，原始命名导出全部丢失。

• CJS 文件（utils.js）：

  exports.add = (a, b) => a + b;
  exports.version = '1.0';

• ESM 中导入：

  import utils from './utils.js'; // ✅ 只能拿到默认导出（整个 exports 对象）
  // import { add } from './utils.js'; // ❌ 报错：add is not exported

• 反过来，ESM 文件被 require 导入时，default 会变成 exports.default，其他命名导出不可见
• 顶层 this：CJS 中指向 module.exports，ESM 中永远是 undefined

最常被忽略的一点：循环依赖时，CJS 返回的是模块初始化中途的 exports 对象（可能含 undefined 属性），而 ESM 返回的是实时绑定的导出绑定（属性值始终是最新的赋值结果）——这决定了你在重构复杂依赖链时，是否需要重写逻辑来规避“未定义访问”。

理论要掌握，实操不能落！以上关于《JS模块化详解：ES Module与CommonJS区别》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！