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

新闻动态

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）三者本质不兼容，不能混用，也不能靠“改个后缀”就自动转换。

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

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

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

写法必须显式包裹：

define(['./a', './b'], function(a, b) {
  return { sum: a.val + b.val };
});

没引入 require.js 就调用 define → define is not defined
即使用了 require.js，也无法直接 import 一个 ES6 模块文件，除非配置插件或转译；反过来，ES6 模块也不能 require('./xxx') AMD 模块
现代构建链路（Vite/Webpack/Rollup）基本不生成 AMD 输出，仅遗留项目或特定 CDN 场景（如 Dojo 1.x）还会遇到

import 和 export 是语法级特性，解析阶段就确定依赖图，不能动态拼接路径（import(expr) 是特例，返回 Promise），且模块顶层 this 是 undefined（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.extensions、transform 插件、甚至重写 require 函数。这些方案脆弱、难调试、且掩盖了模块语义差异。

Webpack 默认能处理 import 和 require 混写，但这是靠内部包装器模拟，实际输出仍是统一格式（如 IIFE 或 ES Module）；它不改变两种模块的执行逻辑差异
Vite 默认只支持 ES Module，遇到 require 会报错，必须用插件（如 vite-plugin-commonjs）做运行时转换，但无法支持所有 CommonJS 动态特性（如基于环境判断的 require(x + y)）
真正该关注的不是“怎么让它们一起跑”，而是“哪些模块可以升级、哪些必须保留、是否值得为遗留模块单独建个兼容层”

17370845950