1. 模块化规范的必要性在早期的JavaScript开发中代码组织方式简单粗暴 - 通过script标签引入多个JS文件。这种方式带来了三大致命问题命名冲突全局作用域下的函数和变量会相互覆盖。比如两个文件都定义了calculate()函数后加载的文件会覆盖前者导致不可预期的行为。依赖管理混乱脚本加载顺序必须手动维护如果B.js依赖A.js就必须确保A.js先加载。随着项目扩大这种隐式依赖关系会变得难以追踪。代码复用困难没有明确的接口定义想要复用某个功能只能复制粘贴代码导致维护成本指数级增长。实际案例我曾接手过一个遗留项目全局有超过200个script标签其中30%的函数存在命名冲突。每次修改都像在拆炸弹稍有不慎就会引发连锁反应。2. CommonJS规范详解2.1 核心设计原理CommonJS诞生于2009年专为服务器端JavaScript设计Node.js采用该规范。其核心思想是每个文件就是一个模块拥有独立作用域通过module.exports暴露接口通过require()同步加载依赖// 模块定义 (math.js) function add(a, b) { return a b } module.exports { add } // 模块使用 (app.js) const math require(./math) console.log(math.add(2, 3)) // 52.2 关键特性解析同步加载机制适合服务器环境模块文件在本地磁盘执行到require()时会阻塞后续代码直到模块加载完成示例数据库连接模块通常采用同步加载确保可用性缓存机制首次加载后模块会被缓存后续require()直接返回缓存结果避免重复执行带来的性能开销// 验证缓存机制 console.log(require.cache) // 查看已缓存模块 delete require.cache[require.resolve(./math)] // 手动清除缓存动态加载能力require()参数可以是动态生成的路径支持条件加载等灵活场景// 动态加载示例 const env process.env.NODE_ENV const config require(./config.${env})2.3 典型应用场景Node.js后端开发内置支持无需额外工具链npm生态大量模块采用该规范工具链开发Webpack、Babel等工具的配置文件构建脚本通常使用CommonJS避坑指南在浏览器端直接使用CommonJS会导致性能问题必须通过Webpack等工具打包转换。3. ES Module规范深度解析3.1 语言级模块方案ES6(ES2015)引入的官方模块标准具有以下核心特征静态化设计import/export必须位于模块顶层依赖关系在编译阶段就能确定支持Tree Shaking等优化// 命名导出 (math.js) export function add(a, b) { return a b } export const PI 3.14 // 默认导出 (logger.js) export default function(msg) { console.log(msg) } // 导入方式 (app.js) import { add, PI } from ./math import log from ./logger3.2 进阶特性详解动态导入通过import()函数实现按需加载返回Promise对象适合路由懒加载等场景// 动态加载示例 button.addEventListener(click, async () { const module await import(./dialog.js) module.open() })复合写法导出立即导入的模块简化模块转发逻辑// 复合导出 export { foo } from ./moduleA export { default as Bar } from ./moduleB循环依赖处理通过活绑定机制解决不同于CommonJS的值拷贝// a.js import { bar } from ./b export const foo foo console.log(bar) // 可以访问到b.js导出的bar // b.js import { foo } from ./a export const bar bar console.log(foo) // 可以访问到a.js导出的foo3.3 浏览器原生支持现代浏览器已原生支持ESMscript typemodule import { add } from ./math.js console.log(add(1, 2)) /script关键限制必须使用完整文件扩展名需要服务端支持MIME类型默认启用严格模式4. 两大规范对比分析4.1 核心差异对照表特性CommonJSES Module加载方式同步异步适用环境Node.js浏览器/Node.js导出机制module.exportsexport导入机制require()import静态分析不支持支持循环依赖处理值拷贝动态绑定动态导入原生支持需import()语法严格模式默认非严格默认严格4.2 互操作性解决方案Node.js中的双模式支持通过package.json的type字段指定.cjs/.mjs扩展名强制指定模块类型// package.json { type: module // 默认ESM }互操作注意事项ESM中可以import CommonJS模块CommonJS中不能require ESM模块默认导出需要特殊处理// ESM中使用CommonJS模块 import _ from lodash // 正确 // CommonJS中使用ESM错误示例 const fs require(fs/promises) // 报错5. 现代开发最佳实践5.1 工具链配置建议TypeScript配置// tsconfig.json { compilerOptions: { module: esnext, moduleResolution: node16 } }Babel预设// .babelrc { presets: [ [babel/preset-env, { modules: false // 保留ESM语法 }] ] }5.2 混合使用策略后端项目新代码使用ESM第三方库保持CommonJS通过动态import()加载旧模块前端项目全部采用ESM打包工具处理兼容性利用Tree Shaking优化体积5.3 性能优化技巧预加载关键模块link relmodulepreload href/critical-module.js代码分割策略// webpack配置 optimization: { splitChunks: { chunks: all } }模块缓存策略# 服务器配置 Cache-Control: public, max-age31536000, immutable从实际项目经验来看ES Module正在成为主流选择。我在最近3年的新项目中都采用纯ESM架构配合Vite等现代工具链开发体验和运行效率都有显著提升。对于存量项目建议采用渐进式迁移策略优先将高频修改的模块转为ESM格式。
1. 模块化规范的必要性在早期的JavaScript开发中代码组织方式简单粗暴 - 通过script标签引入多个JS文件。这种方式带来了三大致命问题命名冲突全局作用域下的函数和变量会相互覆盖。比如两个文件都定义了calculate()函数后加载的文件会覆盖前者导致不可预期的行为。依赖管理混乱脚本加载顺序必须手动维护如果B.js依赖A.js就必须确保A.js先加载。随着项目扩大这种隐式依赖关系会变得难以追踪。代码复用困难没有明确的接口定义想要复用某个功能只能复制粘贴代码导致维护成本指数级增长。实际案例我曾接手过一个遗留项目全局有超过200个script标签其中30%的函数存在命名冲突。每次修改都像在拆炸弹稍有不慎就会引发连锁反应。2. CommonJS规范详解2.1 核心设计原理CommonJS诞生于2009年专为服务器端JavaScript设计Node.js采用该规范。其核心思想是每个文件就是一个模块拥有独立作用域通过module.exports暴露接口通过require()同步加载依赖// 模块定义 (math.js) function add(a, b) { return a b } module.exports { add } // 模块使用 (app.js) const math require(./math) console.log(math.add(2, 3)) // 52.2 关键特性解析同步加载机制适合服务器环境模块文件在本地磁盘执行到require()时会阻塞后续代码直到模块加载完成示例数据库连接模块通常采用同步加载确保可用性缓存机制首次加载后模块会被缓存后续require()直接返回缓存结果避免重复执行带来的性能开销// 验证缓存机制 console.log(require.cache) // 查看已缓存模块 delete require.cache[require.resolve(./math)] // 手动清除缓存动态加载能力require()参数可以是动态生成的路径支持条件加载等灵活场景// 动态加载示例 const env process.env.NODE_ENV const config require(./config.${env})2.3 典型应用场景Node.js后端开发内置支持无需额外工具链npm生态大量模块采用该规范工具链开发Webpack、Babel等工具的配置文件构建脚本通常使用CommonJS避坑指南在浏览器端直接使用CommonJS会导致性能问题必须通过Webpack等工具打包转换。3. ES Module规范深度解析3.1 语言级模块方案ES6(ES2015)引入的官方模块标准具有以下核心特征静态化设计import/export必须位于模块顶层依赖关系在编译阶段就能确定支持Tree Shaking等优化// 命名导出 (math.js) export function add(a, b) { return a b } export const PI 3.14 // 默认导出 (logger.js) export default function(msg) { console.log(msg) } // 导入方式 (app.js) import { add, PI } from ./math import log from ./logger3.2 进阶特性详解动态导入通过import()函数实现按需加载返回Promise对象适合路由懒加载等场景// 动态加载示例 button.addEventListener(click, async () { const module await import(./dialog.js) module.open() })复合写法导出立即导入的模块简化模块转发逻辑// 复合导出 export { foo } from ./moduleA export { default as Bar } from ./moduleB循环依赖处理通过活绑定机制解决不同于CommonJS的值拷贝// a.js import { bar } from ./b export const foo foo console.log(bar) // 可以访问到b.js导出的bar // b.js import { foo } from ./a export const bar bar console.log(foo) // 可以访问到a.js导出的foo3.3 浏览器原生支持现代浏览器已原生支持ESMscript typemodule import { add } from ./math.js console.log(add(1, 2)) /script关键限制必须使用完整文件扩展名需要服务端支持MIME类型默认启用严格模式4. 两大规范对比分析4.1 核心差异对照表特性CommonJSES Module加载方式同步异步适用环境Node.js浏览器/Node.js导出机制module.exportsexport导入机制require()import静态分析不支持支持循环依赖处理值拷贝动态绑定动态导入原生支持需import()语法严格模式默认非严格默认严格4.2 互操作性解决方案Node.js中的双模式支持通过package.json的type字段指定.cjs/.mjs扩展名强制指定模块类型// package.json { type: module // 默认ESM }互操作注意事项ESM中可以import CommonJS模块CommonJS中不能require ESM模块默认导出需要特殊处理// ESM中使用CommonJS模块 import _ from lodash // 正确 // CommonJS中使用ESM错误示例 const fs require(fs/promises) // 报错5. 现代开发最佳实践5.1 工具链配置建议TypeScript配置// tsconfig.json { compilerOptions: { module: esnext, moduleResolution: node16 } }Babel预设// .babelrc { presets: [ [babel/preset-env, { modules: false // 保留ESM语法 }] ] }5.2 混合使用策略后端项目新代码使用ESM第三方库保持CommonJS通过动态import()加载旧模块前端项目全部采用ESM打包工具处理兼容性利用Tree Shaking优化体积5.3 性能优化技巧预加载关键模块link relmodulepreload href/critical-module.js代码分割策略// webpack配置 optimization: { splitChunks: { chunks: all } }模块缓存策略# 服务器配置 Cache-Control: public, max-age31536000, immutable从实际项目经验来看ES Module正在成为主流选择。我在最近3年的新项目中都采用纯ESM架构配合Vite等现代工具链开发体验和运行效率都有显著提升。对于存量项目建议采用渐进式迁移策略优先将高频修改的模块转为ESM格式。
