JavaScript模块化：从CommonJS到ES Modules的深度解析-开发者社区

1. 模块化发展背景与核心概念

JavaScript模块化的发展历程可以看作是一部解决代码组织问题的进化史。早期的JS代码都是直接写在script标签里，随着前端项目越来越复杂，这种简单粗暴的方式带来了全局污染、依赖混乱等问题。于是社区先后出现了多种模块化方案，最终在ES6中官方标准化了模块系统。

1.1 为什么需要模块化

想象一下你正在开发一个大型电商网站。如果没有模块化，所有商品展示、购物车、用户登录的代码都混在一起，就像把衣服、餐具、书籍全部扔进同一个柜子。当你需要修改购物车功能时，可能不小心影响到用户登录模块，这种耦合会带来巨大的维护成本。

模块化通过以下方式解决这些问题：

作用域隔离：每个模块有自己的作用域，避免全局污染
明确依赖：模块间依赖关系清晰可见
代码复用：公共功能可以抽离为独立模块
团队协作：不同开发者可以并行开发不同模块

1.2 主流模块化方案对比

目前JavaScript主要有两种模块化规范：

CommonJS (CJS)：
- Node.js默认采用的模块系统
- 使用require()导入，module.exports导出
- 典型特点：同步加载、运行时解析
ES Modules (ESM)：
- ES6语言标准的一部分
- 使用import/export语法
- 典型特点：静态分析、编译时解析

提示：浏览器原生支持ESM，Node.js从v12开始也支持ESM（需要在package.json中设置"type": "module"）

2. CommonJS深度解析

2.1 基本使用模式

CommonJS模块的基本结构非常简单：

// math.js - 定义模块 function add(a, b) { return a + b } module.exports = { add: add } // app.js - 使用模块 const math = require('./math.js') console.log(math.add(1, 2)) // 3

2.2 核心特性剖析

2.2.1 运行时加载机制

CommonJS模块是在代码执行到require()语句时才加载的。这意味着：

模块加载是同步的
可以根据条件动态决定是否加载模块
模块路径可以动态生成

// 动态加载示例 const moduleName = someCondition ? 'moduleA' : 'moduleB' const module = require(`./${moduleName}.js`)

2.2.2 值拷贝与缓存

CommonJS模块导出的是值的拷贝，这一点非常重要：

// counter.js let count = 0 function increment() { count++ } module.exports = { count: count, increment: increment } // app.js const counter = require('./counter.js') console.log(counter.count) // 0 counter.increment() console.log(counter.count) // 0 (不会改变)

这是因为count在导出时被复制了一份，模块内部的count变化不会反映到导出的拷贝上。

2.2.3 循环依赖处理

CommonJS处理循环依赖时有一些特殊行为：

// a.js console.log('a starting') exports.done = false const b = require('./b.js') console.log('in a, b.done =', b.done) exports.done = true console.log('a done') // b.js console.log('b starting') exports.done = false const a = require('./a.js') console.log('in b, a.done =', a.done) exports.done = true console.log('b done') // main.js console.log('main starting') const a = require('./a.js') const b = require('./b.js') console.log('in main, a.done=', a.done, 'b.done=', b.done)

输出结果：

main starting a starting b starting in b, a.done = false b done in a, b.done = true a done in main, a.done= true b.done= true

这表明CommonJS在遇到循环依赖时，会返回模块的部分执行结果，这可能导致一些意料之外的行为。

3. ES Modules全面解读

3.1 基本语法结构

ESM使用import和export关键字来定义模块：

// math.js - 导出模块 export function add(a, b) { return a + b } // app.js - 导入模块 import { add } from './math.js' console.log(add(1, 2)) // 3

3.2 导出方式详解

3.2.1 命名导出(Named Exports)

命名导出允许一个模块导出多个值：

// 方式1：声明时直接导出 export const PI = 3.14 export function circleArea(r) { return PI * r * r } // 方式2：先声明后导出 const PI = 3.14 function circleArea(r) { return PI * r * r } export { PI, circleArea } // 方式3：导出时重命名 export { PI as pi, circleArea as area }

3.2.2 默认导出(Default Export)

每个模块可以有一个默认导出：

// 方式1：直接导出匿名值 export default function(r) { return 3.14 * r * r } // 方式2：导出已命名值 function circleArea(r) { return 3.14 * r * r } export default circleArea // 方式3：导出对象 export default { PI: 3.14, circleArea(r) { return this.PI * r * r } }

注意：默认导出本质上只是给导出值命名为"default"，导入时可以任意命名

3.2.3 复合导出模式

可以同时使用命名导出和默认导出：

// math.js export const PI = 3.14 export default function circleArea(r) { return PI * r * r } // app.js import calculateArea, { PI } from './math.js'

3.3 导入方式详解

3.3.1 命名导入

import { add, subtract } from './math.js'

可以重命名导入的值：

import { add as addNumbers, subtract as minus } from './math.js'

3.3.2 默认导入

import circleArea from './math.js'

默认导入的名称可以任意指定：

import myAreaFunction from './math.js'

3.3.3 命名空间导入

将整个模块导入为一个命名空间对象：

import * as math from './math.js' math.add(1, 2) math.PI

3.3.4 副作用导入

仅执行模块代码，不导入任何值：

import './analytics.js'

常用于：

执行polyfill
初始化监控
加载CSS文件

3.3.5 动态导入

ES2020引入的动态导入语法：

// 按需加载 button.addEventListener('click', async () => { const module = await import('./dialog.js') module.open() }) // 条件加载 if (user.isAdmin) { const adminModule = await import('./admin.js') }

3.4 ESM的核心特性

3.4.1 静态解析

ESM的导入导出必须在顶层作用域，这使得：

工具可以在编译时分析依赖关系
支持tree shaking优化
错误可以在早期被发现

// 错误示例 if (condition) { import './module.js' // SyntaxError }

3.4.2 实时绑定(Live Binding)

ESM导出的是值的引用，而不是拷贝：

// counter.js export let count = 0 export function increment() { count++ } // app.js import { count, increment } from './counter.js' console.log(count) // 0 increment() console.log(count) // 1

3.4.3 顶层await

ESM支持在模块顶层使用await：

// data.js const data = await fetch('/api/data').then(r => r.json()) export { data } // app.js import { data } from './data.js' console.log(data) // 已经解析好的数据

4. CJS与ESM的深度对比

4.1 加载时机对比

特性	CommonJS	ES Modules
加载时机	运行时动态加载	编译时静态解析
语法位置	可出现在任何位置	必须位于顶层作用域
动态导入	原生支持require()	需要import()语法

4.2 值传递机制对比

// counter.js (CommonJS) let count = 0 function increment() { count++ } module.exports = { count, increment } // app.js const counter = require('./counter.js') console.log(counter.count) // 0 counter.increment() console.log(counter.count) // 0 (不变) // counter.mjs (ESM) export let count = 0 export function increment() { count++ } // app.mjs import { count, increment } from './counter.mjs' console.log(count) // 0 increment() console.log(count) // 1 (变化)

4.3 循环依赖处理对比

ESM处理循环依赖的方式与CJS不同：

// a.mjs import { bDone } from './b.mjs' export const aDone = true console.log('in a:', bDone) // b.mjs import { aDone } from './a.mjs' export const bDone = true console.log('in b:', aDone) // main.mjs import './a.mjs'

这会抛出引用错误，因为a.mjs和b.mjs互相依赖，形成死锁。ESM的这种严格处理方式虽然看起来更受限，但能避免CJS中那些难以追踪的循环依赖问题。

4.4 浏览器与Node.js环境差异

在浏览器中使用ESM需要注意：

需要添加type="module"属性
文件路径必须完整（不能省略.js扩展名）
默认启用严格模式

<script type="module"> import { add } from './math.js' </script>

在Node.js中使用ESM：

文件扩展名需为.mjs，或在package.json中设置"type": "module"
一些Node.js特有的全局变量（如__dirname）不可用
部分核心模块的导入方式不同

5. Tree Shaking深度解析

5.1 工作原理

Tree shaking是现代打包工具（如Webpack、Rollup）的一项重要优化技术，其工作原理是：

构建依赖图：通过静态分析确定模块间的导入导出关系
标记未使用代码：识别出哪些导出未被任何模块导入
删除死代码：安全地移除未被使用的代码

5.2 最佳实践

5.2.1 有利于Tree Shaking的写法

// 方式1：直接导出独立函数 export function add(a, b) { return a + b } export function subtract(a, b) { return a - b } // 方式2：使用纯函数 export const utils = { add(a, b) { return a + b }, subtract(a, b) { return a - b } }

5.2.2 不利于Tree Shaking的写法

// 方式1：导出包含副作用的代码 export const utils = { add(a, b) { console.log('adding') // 副作用 return a + b } } // 方式2：动态属性访问 const methods = { add(a, b) { return a + b }, subtract(a, b) { return a - b } } export default methods

5.3 常见问题解答

5.3.1 import * as utils vs import { add }

// 会引入整个utils模块，不利于tree shaking import * as utils from './utils.js' utils.add(1, 2) // 只引入add函数，其他未使用的导出会被移除 import { add } from './utils.js' add(1, 2)

5.3.2 CSS文件会被Tree Shaking吗？

import './styles.css' // 不会被移除

CSS文件通常包含影响页面样式的"副作用"，打包工具会保留它们。同样，图片资源、字体文件等也不会被tree shaking移除。

5.3.3 如何确保第三方库支持Tree Shaking？

检查库是否提供ESM版本
使用支持sideEffects标志的打包工具
避免整体导入：

// 不推荐 import _ from 'lodash' // 推荐 import { debounce } from 'lodash-es'

6. 模块化实践建议

6.1 项目结构组织

良好的模块化项目结构示例：

src/ components/ // UI组件 Button/ index.js // 主入口 styles.css // 样式 utils.js // 组件专用工具 utils/ // 公共工具函数 math.js string.js services/ // 数据服务 api.js cache.js store/ // 状态管理 index.js modules/ user.js cart.js

6.2 代码分割策略

路由级分割：

const Home = lazy(() => import('./pages/Home')) const About = lazy(() => import('./pages/About'))

功能级分割：

const handleClick = async () => { const { showNotification } = await import('./utils/notifications') showNotification('Hello!') }

第三方库分割：

// webpack配置 optimization: { splitChunks: { chunks: 'all' } }

6.3 性能优化技巧

预加载关键模块：

<link rel="modulepreload" href="/critical-module.js">

使用动态导入+ Suspense：

const OtherComponent = React.lazy(() => import('./OtherComponent')) function MyComponent() { return ( <Suspense fallback={<div>Loading...</div>}> <OtherComponent /> </Suspense> ) }

避免深层嵌套导入：

// 不推荐 import { utils } from '../../../../shared/utils' // 推荐 // 使用alias配置或模块解析优化 import { utils } from '@/shared/utils'

7. 常见问题与解决方案

7.1 混合使用CJS和ESM

在Node.js中同时使用两种模块系统时：

在ESM中导入CJS模块：

// ESM中 import cjsModule from './cjs-module.js' // CJS模块的module.exports会作为默认导出

在CJS中导入ESM模块：

// 必须使用动态import() async function loadESM() { const esmModule = await import('./esm-module.mjs') }

7.2 模块缓存问题

ESM和CJS都有模块缓存机制，但行为略有不同：

清除CJS缓存：

delete require.cache[require.resolve('./module.js')]

ESM缓存：无法直接清除，需要重启应用或使用模块热替换(HMR)

7.3 浏览器兼容性处理

对于不支持ESM的旧浏览器：

使用打包工具转换为ES5
提供nomodule回退：

<script type="module" src="app.js"></script> <script nomodule src="app-legacy.js"></script>

使用polyfill（谨慎选择，会增加体积）

7.4 模块解析差异

不同环境下模块解析规则不同：

浏览器ESM：
- 必须使用完整路径或相对路径
- 需要文件扩展名
Node.js ESM：
- 支持目录导入（查找index.js）
- 可以省略扩展名
- 支持package.json的exports字段
打包工具：
- 通常支持以上所有规则
- 可能还有额外alias配置

8. 高级模块模式

8.1 模块热替换(HMR)

// webpack HMR示例 if (module.hot) { module.hot.accept('./module.js', () => { // 模块更新时的回调 console.log('模块已更新') }) }

8.2 模块联邦(Module Federation)

webpack 5引入的跨应用模块共享：

// app1 webpack配置 new ModuleFederationPlugin({ name: 'app1', filename: 'remoteEntry.js', exposes: { './Button': './src/components/Button' } }) // app2 webpack配置 new ModuleFederationPlugin({ name: 'app2', remotes: { app1: 'app1@http://localhost:3001/remoteEntry.js' } }) // app2中使用app1的模块 import('app1/Button').then(Button => { // 使用Button组件 })

8.3 条件导出与环境区分

package.json中的高级导出配置：

{ "exports": { ".": { "import": "./dist/module.mjs", "require": "./dist/common.js", "default": "./dist/legacy.js" }, "./feature": { "browser": "./feature-browser.js", "node": "./feature-node.js" } } }

9. 工具链支持

9.1 打包工具对比

工具	Tree Shaking	代码分割	HMR	模块联邦
Webpack	优秀	优秀	支持	支持
Rollup	极佳	中等	插件	不支持
Parcel	良好	良好	支持	不支持
Vite	优秀	优秀	极快	支持

9.2 Babel配置

处理模块语法的关键插件：

{ "presets": [ ["@babel/preset-env", { "modules": false // 保留ESM语法 }] ] }

9.3 TypeScript配置

{ "compilerOptions": { "module": "esnext", // 输出ESM "moduleResolution": "node" // 模块解析策略 } }

10. 未来发展趋势

10.1 原生导入映射(Import Maps)

<script type="importmap"> { "imports": { "lodash": "https://unpkg.com/lodash-es@4.17.21/lodash.js" } } </script> <script type="module"> import { debounce } from 'lodash' // 实际从CDN加载 </script>

10.2 更细粒度的代码分割

如函数级、组件级的按需加载。

10.3 WebAssembly模块集成

import init from './module.wasm' init().then(instance => { instance.exports.myFunction() })

在实际项目中，我通常会根据以下原则选择模块方案：

新项目优先使用ESM
库开发同时提供ESM和CJS版本
动态导入用于优化性能关键路径
保持模块职责单一，控制模块体积
定期审查模块依赖关系，避免过度耦合

模块化看似简单，但在大型项目中正确运用需要持续的经验积累。特别是在处理性能优化、代码分割和缓存策略时，往往需要根据具体场景做出权衡。