javascript中的模块加载器如何工作_比较CommonJS、AMD与ES6模块系统【教程】

JavaScript模块系统分CommonJS、AMD、ES6 Module三类,本质不兼容,需构建工具桥接;CommonJS仅Node同步运行,浏览器无require;AMD依赖require.js异步加载;ES6 Module为原生静态模块,需type="module"或.mjs。

JavaScript 模块加载器不是“一个东西”,而是不同规范在不同时期对「如何拆分代码、声明依赖、按需执行」给出的解决方案。CommonJS、AMD、ES6 Module(import/export)三者本质不兼容,不能混用,也不能靠“改个后缀”就自动转换。

CommonJS 只在 Node.js 里同步工作,浏览器直接跑会报 require is not defined

Node.js 的 require() 是同步读取文件、立即执行、返回模块导出对象。它依赖 Node 的文件系统和运行时封装,浏览器没有 require 全局函数,也没有同步读本地文件的能力。

  • 典型错误:把 index.js 直接引入,里面写了 const fs = require('fs') → 浏览器报错 require is not defined
  • 常见误解:以为 Babel 把 import 编译成 require 就等于支持 CommonJS 浏览器运行 —— 实际上只是语法转换,仍需打包工具(如 Webpack)注入运行时来模拟 require
  • Node.js v12+ 虽支持 .mjstype: "module",但此时 require() 不可用,import 才是默认行为,和传统 CommonJS 环境已隔离

AMD 是为浏览器异步加载设计的,但需要 define() 包裹且依赖 require.js 运行时

AMD(Asynchronous Module Definition)解决的是“页面不卡死”的问题:模块可以并行下载、按依赖顺序执行,不阻塞渲染。但它不是语言原生特性,必须靠库(如 require.js)提供 define()require() 函数。

  • 写法必须显式包裹:
    define(['./a', './b'], function(a, b) {
      return { sum: a.val + b.val };
    });
  • 没引入 require.js 就调用 definedefine is not defined
  • 即使用了 require.js,也无法直接 import 一个 ES6 模块文件,除非配置插件或转译;反过来,ES6 模块也不能 require('./xxx') AMD 模块
  • 现代构建链路(Vite/Webpack/Rollup)基本不生成 AMD 输出,仅遗留项目或特定 CDN 场景(如 Dojo 1.x)还会遇到

ES6 Module 是浏览器和 Node.js 都原生支持的静态模块系统,但加载时机和 this 行为与 CommonJS 不同

importexport 是语法级特性,解析阶段就确定依赖图,不能动态拼接路径(import(expr) 是特例,返回 Promise),且模块顶层 thisundefined(CommonJS 中是 exports 对象)。

  • 浏览器中必须用 ,否则 import 语法报错;且模块默认是 strict mode
  • Node.js 中要加 "type": "module"package.json,或用 .mjs 后缀,否则 import 会被当作语法错误(除非用 --experimental-modules,但已废弃)
  • export default 导出的是值的绑定(live binding),不是拷贝 —— 如果模块内部改了 let x = 1,其他模块 import { x } 看到的也会变;而 CommonJS 的 module.exports = {...} 是导出时的一次性快照
  • import() 动态导入返回 Promise,可用于条件加载或路由懒加载:
    if (needChart) {
      const { Chart } = await import('./chart.js');
      new Chart();
    }

混用模块系统的代价远高于收益,迁移时优先选构建工具而非手动桥接

试图让 import 直接加载 CommonJS 模块(或反之),往往需要配置 resolve.extensionstransform 插件、甚至重写 require 函数。这些方案脆弱、难调试、且掩盖了模块语义差异。

  • Webpack 默认能处理 importrequire 混写,但这是靠内部包装器模拟,实际输出仍是统一格式(如 IIFE 或 ES Module);它不改变两种模块的执行逻辑差异
  • Vi

    te 默认只支持 ES Module,遇到 require 会报错,必须用插件(如 vite-plugin-commonjs)做运行时转换,但无法支持所有 CommonJS 动态特性(如基于环境判断的 require(x + y)
  • 真正该关注的不是“怎么让它们一起跑”,而是“哪些模块可以升级、哪些必须保留、是否值得为遗留模块单独建个兼容层”