JavaScript 模块化演进：从全局污染、IIFE 到 ES Module 的终极形态

一、为什么前端必须搞「模块化」？

在 jQuery 时代，我们习惯将代码写在 <script> 标签里，或者通过 CDN 引入各种插件。随着项目规模扩大，这种「面条式代码」带来了灾难性的后果：变量名冲突（var user = ... 覆盖了别人的 user）、依赖顺序混乱（必须先引 A 再引 B）、无法按需加载（为了用一个函数引入了整个库）。

模块化的本质是封装与解耦。它将复杂的系统拆解为独立的小单元，每个单元拥有私有作用域，只暴露必要的接口。本文将带你回顾模块化的演进历史，并彻底搞懂现代构建工具背后的原理。

二、模块化的底层基石：作用域与加载机制

要理解模块化，必须先理解 JavaScript 是如何管理代码边界的。

• 全局作用域：ES5 之前的默认环境。所有变量挂载在 window 上，极易污染。
• 函数作用域：利用函数创建私有空间。这是早期模块化的核心手段。
• 文件作用域：ES6 Module 引入的概念。每个 .js 文件天然是一个独立的模块，拥有自己的顶级作用域。

两种核心的导出/导入范式

1. 动态运行时（CommonJS）：模块在代码执行时才加载，输出的是值的拷贝（浅拷贝）。适合服务端（Node.js），因为文件都在本地磁盘，读取极快。
2. 静态编译时（ESM）：模块在编译阶段就确定了依赖关系，输出的是值的引用（动态绑定）。适合浏览器端，因为支持 Tree Shaking（摇树优化），能提前剔除死代码。

经典面试题：CommonJS 和 ESM 的区别？

// counter.js
let count = 0;
function add() { count++; }
module.exports = { count, add }; // CJS: 导出时 count 是 0 的拷贝
export { count, add };           // ESM: 导出的是 count 的引用

在引入方修改 count 或调用 add 后，CJS 的 count 依然是 0，而 ESM 的 count 会变为 1。这是因为 ESM 建立了动态映射关系。

三、模块化演进的四大里程碑

1. 全局污染时代（Global Pattern）

最原始的阶段。所有变量裸露在全局。

// utils.js
var name = "Utils";
function log() { console.log(name); }
// main.js
log(); // 如果别人也定义了 log，这里就炸了

痛点：毫无安全性可言，大型项目无法维护。

2. IIFE 闭包版（Immediately Invoked Function Expression）

通过立即执行函数创造私有作用域，只把必要的接口挂载到全局对象上。这是 jQuery 等库的经典写法。

var MyModule = (function() {
  var privateVar = "secret"; // 外部无法访问
  
  function publicMethod() {
    return privateVar;
  }
  
  return {
    publicMethod: publicMethod
  };
})();

console.log(MyModule.publicMethod()); // "secret"

优点：解决了变量冲突。
缺点：依赖关系依然靠人肉保证顺序，无法自动分析依赖图。

3. CommonJS 同步版（Node.js 标准）

Node.js 诞生后，CJS 成为服务端标准。它使用 require 同步加载文件。

const fs = require('fs'); // 同步阻塞读取文件
const data = fs.readFileSync('./test.txt');
module.exports = { data };

痛点：浏览器端不能用！因为网络请求是异步的，同步加载会导致页面假死。于是诞生了 AMD (RequireJS) 和 CMD (SeaJS)，但它们语法繁琐，逐渐被历史淘汰。

4. ES Module 静态版（现代标准）

ES2015 原生支持的模块化方案。

// math.js
export const PI = 3.14;
export default function add(a, b) { return a + b; }

// main.js
import add, { PI } from './math.js';

优点：

• 静态分析：编译器能在打包前知道用了什么，没用到的直接删掉（Tree Shaking）。
• 异步加载：天然支持浏览器的异步特性。
• 循环引用处理：比 CJS 更优雅地处理了模块间的循环依赖。

四、四种现代工程化解决方案

方案一：Webpack 打包版（Bundle）

Webpack 的核心思想是「一切皆模块」。它将所有模块打包成一个或几个巨大的 Bundle 文件。

// webpack.config.js
module.exports = {
  entry: './src/index.js',
  output: { filename: 'bundle.js' },
  module: {
    rules: [
      { test: /\.css$/, use: ['style-loader', 'css-loader'] } // 连 CSS 都能当模块引
    ]
  }
};

适用场景：复杂的大型应用，需要精细的代码分割、兼容性处理（Babel）。

方案二：Vite 原生 ESM 版（Unbundled）

Vite 利用了现代浏览器原生支持 ESM 的特性。开发环境下不打包，直接让浏览器去请求各个模块。

浏览器请求 index.html -> 发现 <script type="module" src="/src/main.js">
-> 浏览器解析 main.js -> 发现 import -> 发起新的 HTTP 请求获取依赖

优点：启动速度极快（毫秒级），因为省去了打包过程。
缺点：生产环境依然需要 Rollup 打包，否则 HTTP 请求太多会慢。

方案三：Monorepo 工作区版（Turborepo/pnpm）

当项目拆分成几十个模块时，如何管理？Monorepo 将所有模块放在一个仓库里，通过 Workspace 协议互相引用。

// package.json
{
  "dependencies": {
    "@my-org/ui": "workspace:*", // 直接引用本地包，不经过 npm
    "@my-org/utils": "workspace:*"
  }
}

优点：代码复用率极高，统一版本管理，原子化提交。

方案四：动态导入版（Code Splitting）

利用 import() 函数实现按需加载，首屏不加载非核心代码。

button.addEventListener('click', async () => {
  const modal = await import('./HeavyModal.js'); // 点击时才下载这个 JS
  modal.open();
});

优点：显著减少首屏体积，提升 LCP 指标。

五、横向对比：构建工具选型指南

六、总结：没有银弹，只有权衡

• 写库：首选 Rollup，产物干净，Tree Shaking 彻底。
• 写应用（Vue/React）：首选 Vite，开发体验极佳。
• 维护老项目/极度复杂的构建逻辑：Webpack 依然是王者，它的 Loader 机制能处理任何奇怪的文件格式。
• Next.js 用户：直接拥抱 Turbopack，这是未来的趋势。

模块化不仅是代码组织方式，更是前端工程化的基石。理解它，你才能从「API 调用师」进阶为「架构师」。