内容运营-伍小仙早几年我还在用 RequireJS 和 SeaJS 折腾异步模块加载的时候，真没想到前端模块化能走到今天这一步。现在打开任意一个 Node.js 项目，require 和 import 混着写是常态；跑到 Vite 或 Next.js 里，纯 ESM 又成了默认。但正因为这套体系演进得太快，很多人对 CJS 和 ESM 的理解停留在“一个用 require、一个用 import”的层面，结果一遇到混用就各种报错。
我见过不少团队在迁移到 ESM 时被 ERR_REQUIRE_ESM 卡住，也见过有人因为循环依赖导致初始化顺序错乱，排查到深夜。这篇文章我不打算做枯燥的规格复述，而是想从一个实际写过大量 Node 服务和前端项目的角度，把 CJS 与 ESM 的区别、混用方式、底层原因和踩坑经验一次性讲透。无论你是在维护老项目，还是在从零搭建新工程，这篇应该都能帮你省下不少查文档的时间。
1. 为什么前端会有两套模块体系：一段历史演进与现状
要说清楚 CJS 和 ESM 的区别，先得知道它们是怎么来的。这不是考古，而是理解很多“诡异行为”的基础。
1.1 CJS 的诞生：一场“被迫”的浏览器侧改革
Node.js 在 2009 年刚出来的时候，JavaScript 语言本身还没有模块概念。浏览器里想复用代码，要么靠全局变量，要么靠 IIFE（立即执行函数）包裹。后果就是命名冲突、依赖顺序难维护，一个稍微大点的项目，光 script 标签的排列顺序就能让人崩溃。
CommonJS 规范就是在这种情况下出现的。它用 require 同步加载模块，用 module.exports 导出内容。这在服务器端没问题，因为 Node 读取的是本地磁盘文件，同步读取的速度可以接受。但浏览器端不行——同步加载意味着页面要卡住等文件下载完，这在网络环境下是不能接受的，所以浏览器端后来走了 AMD/CMD 那条异步路线。
CJS 的关键特性有三个，后面很多坑都源于它们：
- 运行时加载：
require是在代码执行到那一行时才去加载模块，所以它可以在 if 语句里、函数里、甚至任意条件分支里调用。 - 拷贝导出：
module.exports导出的值，在模块加载完成后就已经确定了。如果导出一个对象，外部拿到的是对象引用的拷贝（严格来说是浅拷贝的引用关系），后续模块内部再修改这个对象，外部其实能看到变化；但如果模块内部把整个module.exports重新赋值了，外部拿到旧引用就不变了。 - 同步执行：加载到一个模块，会同步执行它的所有代码，然后才返回
exports。
1.2 ESM 的出现：语言层面的正统解决方案
ES6 在 2015 年正式推出了 import / export 语法，这才是 JavaScript 语言自带的模块系统。和 CJS 相比，它有几个本质性的改变：
- 静态解析：
import语句必须写在模块顶层，不能在 if 或函数里写。这样做的好处是引擎在代码执行前就能分析出完整的依赖关系树，可以做 tree-shaking、按需加载等优化。 - 实时绑定：ESM 导出的是活引用（live binding）。模块内部修改变量，外部导入的地方能看到最新值。
- 异步加载：ESM 的设计考虑到了浏览器环境，模块加载是异步的，可以配合
import()动态加载。
这两套体系在语法和加载机制上的差异，导致了它们在很多场景下的行为完全不一样。举个最简单的例子：
javascript复制// CJS 中，require 可以写在这里
if (someCondition) {
const fs = require('fs');
}
// ESM 中，import 必须提升到顶层
if (someCondition) {
import fs from 'fs'; // 语法错误
}
这不是语法限制这么简单，而是设计哲学的根本不同。CJS 是“执行到哪就加载到哪”，ESM 是“先看清楚依赖关系，再做加载决策”。
1.3 当下的格局：双模块共存的中间态
到 2025 年了，Node.js 已经支持 ESM 很多年，浏览器原生支持也非常完善，按理说应该全面切换到 ESM 了。但现实是，npm 上几十万个包仍然是 CJS 格式，很多维护良好的老项目不可能一夜之间重写。所以我们现在处于一个“双模块共存”的过渡期。
这个过渡期带来了一个很实际的问题：Node.js 和打包器需要同时支持两种模块系统，并且要处理它们之间的互操作。于是就有了 .mjs、.cjs 这些扩展名，有了 package.json 里的 type: "module" 字段，有了 exports 字段的条件导出。理解这些规则，是在现代前端工程里混用两种模块的基础。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. CJS 与 ESM 的核心差异：不是语法不同那么简单
很多人以为 CJS 和 ESM 的区别就是 require vs import，其实语法只是表象，底层的加载机制、作用域、this 指向都有很大不同。我把它们系统的拆一下。
2.1 加载时机：运行时解析 vs 静态解析
CJS 是同步加载，模块在 require 被调用时才执行。这意味着：
javascript复制// 文件 a.cjs
console.log('a 开始加载');
const b = require('./b.cjs');
console.log('a 加载完成');
// 文件 b.cjs
console.log('b 被加载了');
module.exports = { name: 'b' };
执行 node a.cjs 的输出顺序是：
code复制a 开始加载
b 被加载了
a 加载完成
而 ESM 不同，import 语句会被提升到模块顶部。即使你把 import 写在文件中间，它也会在模块其他代码执行之前先完成依赖加载：
javascript复制// 文件 a.mjs
console.log('a 开始执行');
import { name } from './b.mjs';
console.log('a 执行完成，name =', name);
// 文件 b.mjs
console.log('b 模块被执行了');
export const name = 'b';
注意，上面这段代码在 ESM 中是合法的，import 会被自动提升。输出顺序是：
code复制b 模块被执行了
a 开始执行
a 执行完成，name = b
这种差异直接影响了模块的初始化顺序。如果你有一个模块初始化时依赖另一个模块的副作用（比如往全局对象上挂东西），在 CJS 和 ESM 下的表现可能就不一样。
2.2 导出绑定：值的拷贝 vs 活引用
这一节是最容易让人困惑的，我实际验证了很多遍才完全确定。
CJS 的 module.exports 本质上是把一个对象赋值给模块的导出。当外部模块 require 它时，拿到的是这个对象