JavaScript模块化规范有哪些演进历程【教程】_技术教程

JavaScript模块化演进始于全局污染等现实问题，历经IIFE、CommonJS（Node.js同步标准）、AMD（浏览器异步方案）到ES Modules（编译时静态标准），现代项目需依环境选型：前端用ESM，Node工具脚本可选CommonJS，跨平台库须明确package.json配置。

JavaScript 模块化不是从 import 开始的，而是被现实逼出来的：全局变量污染、依赖顺序难控、无法复用——早期开发者只能靠标签硬拼，手写命名空间，甚至用 IIFE “模拟”模块。

CommonJS 是 Node.js 的事实标准

Node.js 诞生后直接采用 CommonJS 规范，用 module.exports 输出，require() 加载。它同步读取文件、适合服务端，但浏览器里直接用会阻塞渲染。

常见错误现象：require is not defined —— 浏览器原生不支持 require()；Cannot find module 'fs' —— 浏览器没有 fs 模块。

require() 是运行时动态解析，路径可以是变量（如 require(name + '.js')），但打包工具（如 Webpack）可能无法静态分析
module.exports = {} 和 exports.xxx = 行为不同：重赋值 exports 会断开与 module.exports 的引用，导致导出为空
CommonJS 模块被多次 require() 时，只执行一次初始化，后续返回缓存结果（即单例）

AMD 和 RequireJS 解决浏览器异步加载

为在浏览器中实现“按需加载+依赖前置”，AMD（Asynchronous Module Definition）出现，代表实现是 RequireJS。它强制声明依赖，用回调函数包裹模块逻辑。

典型写法：define(['jquery', './util'], function($, util) { return { ... }; });

依赖必须提前写死在数组里，不能动态 require(condition ? 'a' : 'b')
每个模块需显式调用 define()，语法冗长，和 CommonJS 不兼容
现代构建工具基本不再推荐 AMD，仅遗留系统或特殊插件场景还会遇到

ES Modules（ESM）是官方标准，但有严格限制

ES2015 正式引入 import/export，成为浏览器和 Node.js 共同支持的模块标准。但它不是运行时行为，而是**编译时静态分析**——这意味着很多动态操作根本不可行。

常见错误现象：Cannot use import statement outside a module（Node.js 需加 "type": "module" 或用 .mjs 后缀）；Dynamic require is not supported（import() 是唯一合法动态方式）。

import 路径必须是字符串字面量，不能是变量或表达式（import(foo) ❌，import('./' + name + '.js') ❌）
import() 返回 Promise，是唯一支持动态路径的方式，但加载结果需用 .then() 或 await
ESM 中 this 是 undefined，且顶层 var/function 声明不会挂到全局，和 CommonJS 行为差异明显
Node.js 对 ESM 的 __dirname 和 __filename 不提供等价物，得用 import.meta.url + fileURLToPath()

现代项目怎么选？看环境，别硬套规范

不是“哪个更新就该用哪个”，而是根据执行环境和构建链路决定：

纯前端项目（Vite / Webpack / Rollup）：统一用 ESM，构建工具会自动处理兼容性
Node.js 工具类脚本（CLI、配置文件）：若需 require('json') 或 fs，CommonJS 更直接；若要发布给 ESM 项目用，得同时提供 exports 字段或双包结构
跨平台库（如 npm 包）：必须在 package.json 中明确 "type": "module" 或使用 "exports" 字段控制入口，否则 ESM 用户会遇到 ERR_REQUIRE_ESM
动态导入逻辑（比如路由懒加载、条件加载组件）：只能走 import()，别试图用 require() 替代