企业官网建设流程全解析

《ES6 入门教程》Module 加载实现详解：浏览器、Node.js 与循环加载机制

【免费下载链接】es6tutorial《ECMAScript 6入门》是一本开源的 JavaScript 语言教程，全面介绍 ECMAScript 6 新增的语法特性。项目地址: https://gitcode.com/gh_mirrors/es/es6tutorial

导读

本文是《ECMAScript 6 入门》开源教程（仓库 README.md 对全书定位为"全面介绍 ECMAScript 6 新引入的语法特性"）中"Module 的加载实现"一章的深度展开，对应仓库 docs/module-loader.md。上一章 docs/module.md 讲解了import、export等模块语法，本文则聚焦这些语法在真实环境中的"落地"问题：浏览器如何通过<script type="module">加载模块、Node.js 如何通过.mjs/package.json字段区分 ESM 与 CommonJS，以及最让开发者头疼的"循环加载"到底是怎么工作的。读完本文，你将掌握 ESM 在浏览器与 Node.js 两端的完整加载规则、package.json中main/exports字段的实战配置，以及用代码示例验证过的循环加载应对方案。

在仓库中，本文位于全书目录第 23 章（见 SUMMARY.md 与 sidebar.md），紧随"Module 的语法"一章，两章共同构成 ES6 模块体系的完整闭环。

浏览器加载 ES6 模块

传统方法：同步加载与浏览器堵塞

在 ES6 模块出现之前，浏览器通过<script>标签加载 JavaScript 脚本，既有页面内嵌脚本，也有外部脚本：

<!-- 页面内嵌的脚本 --> <script type="application/javascript"> // module code </script> <!-- 外部脚本 --> <script type="application/javascript" src="path/to/myModule.js"> </script>

由于浏览器脚本的默认语言就是 JavaScript，因此type="application/javascript"可以省略。默认情况下，浏览器是同步加载脚本的：渲染引擎遇到<script>标签就会停下来，等执行完脚本再继续向下渲染；如果是外部脚本，还必须加上下载时间。如果脚本体积很大，下载和执行时间很长，就会造成浏览器堵塞，用户会明显感觉到页面"卡死"、毫无响应。

defer 与 async：两种异步加载语法

为了解决阻塞问题，浏览器允许脚本异步加载，语法如下：

<script src="path/to/myModule.js" defer></script> <script src="path/to/myModule.js" async></script>

打开defer或async属性后，渲染引擎遇到这一行命令就会开始下载外部脚本，但不会等它下载和执行，而是直接执行后面的命令。两者的区别在于执行时机：

• defer要等到整个页面在内存中正常渲染结束（DOM 结构完全生成、其他脚本执行完成）才执行，即"渲染完再执行"；多个defer脚本会按照在页面中出现的顺序依次加载。
• async一旦下载完，渲染引擎就会中断当前渲染去执行该脚本，执行完再继续渲染，即"下载完就执行"；多个async脚本不保证加载顺序。

加载规则：type="module"

浏览器加载 ES6 模块仍然使用<script>标签，但必须加入type="module"属性：

<script type="module" src="./foo.js"></script>

一旦type设为module，浏览器就认定这是一个 ES6 模块。关键行为如下：

1. 异步加载：带有type="module"的<script>都是异步加载，不会堵塞浏览器——等到整个页面渲染完再执行模块脚本，等同于打开了defer属性：

<script type="module" src="./foo.js"></script> <!-- 等同于 --> <script type="module" src="./foo.js" defer></script>

2. 按出现顺序执行：如果网页有多个<script type="module">，它们会按照在页面中出现的顺序依次执行。
3. async 可以叠加：<script type="module">也可以打开async属性，此时只要模块加载完成，渲染引擎就会中断渲染立即执行，多个模块不再按出现顺序执行，而是"谁先加载完谁先执行"：

<script type="module" src="./foo.js" async></script>

4. 支持内嵌模块：ES6 模块允许内嵌在网页中，语法行为与加载外部脚本完全一致：

<script type="module"> import utils from "./utils.js"; // other code </script>

例如 jQuery 就支持这种模块化加载方式：

<script type="module"> import $ from "./jquery/src/jquery.js"; $('#message').text('Hi from jQuery!'); </script>

外部模块脚本的五个注意点

对于外部的模块脚本（如上例的foo.js），有以下几点需要特别注意：

• 模块作用域：代码在模块作用域中运行，而不是全局作用域，模块内部的顶层变量外部不可见。
• 自动严格模式：模块脚本自动采用严格模式，不管有没有声明use strict。
• 可以使用 import/export：模块之中可以使用import命令加载其他模块（.js后缀不可省略，需提供绝对 URL 或相对 URL），也可以使用export命令输出对外接口。
• 顶层 this 为 undefined：模块顶层的this关键字返回undefined，而不是指向window，因此在模块顶层使用this没有意义。
• 只执行一次：同一个模块如果加载多次，将只执行一次。

下面是一个示例模块：

import utils from 'https://example.com/js/utils.js'; const x = 1; console.log(x === window.x); //false console.log(this === undefined); // true

利用"顶层this等于undefined"这个语法点，可以侦测当前代码是否运行在 ES6 模块之中：

const isNotModuleScript = this !== undefined;

这一特性与上一章 docs/module.md 中"严格模式"一节提到的"ES6 模块之中，顶层的this指向undefined"完全一致，是模块代码区别于传统脚本的最直观特征之一。

ES6 模块与 CommonJS 模块的三大差异

在讨论 Node.js 加载 ES6 模块之前，必须先理解 ES6 模块与 CommonJS 模块是完全不同的两套体系，它们有三个重大差异：

1. CommonJS 模块输出的是值的拷贝，ES6 模块输出的是值的引用；
2. CommonJS 模块是运行时加载，ES6 模块是编译时输出接口；
3. CommonJS 模块的require()是同步加载，ES6 模块的import命令是异步加载，有一个独立的模块依赖解析阶段。

第二个差异的根源在于：CommonJS 加载的是一个对象（即module.exports属性），该对象只有在脚本运行完才会生成；而 ES6 模块不是对象，它的对外接口只是一种静态定义，在代码静态解析阶段就会生成。这与上一章讲的"ES6 模块的设计思想是尽量静态化，使得编译时就能确定模块的依赖关系"一脉相承。

重点：值的拷贝 vs 值的引用

先看 CommonJS 的行为。模块文件lib.js输出内部变量counter和改写它的内部方法incCounter：

// lib.js var counter = 3; function incCounter() { counter++; } module.exports = { counter: counter, incCounter: incCounter, };

然后在main.js中加载这个模块：

// main.js var mod = require('./lib'); console.log(mod.counter); // 3 mod.incCounter(); console.log(mod.counter); // 3

可以看到，lib.js内部的变化影响不到输出的mod.counter——因为mod.counter是一个原始类型的值，会被缓存。除非把输出值改写成函数（取值器），才能读取到内部变动后的值：

// lib.js var counter = 3; function incCounter() { counter++; } module.exports = { get counter() { return counter }, incCounter: incCounter, };

此时再执行main.js，就可以正确读取内部变量counter的变动：

$ node main.js 3 4

ES6 模块的运行机制完全不同。JS 引擎对脚本做静态分析时，遇到import命令就会生成一个只读引用；等到脚本真正执行时，再根据这个只读引用到被加载的模块内部去取值。换言之，ES6 的import有点像 Unix 系统的"符号连接"：原始值变了，import加载的值也会跟着变。因此 ES6 模块是动态引用，不会缓存值，模块里的变量绑定其所在的模块。用同样的例子对比：

// lib.js export let counter = 3; export function incCounter() { counter++; } // main.js import { counter, incCounter } from './lib'; console.log(counter); // 3 incCounter(); console.log(counter); // 4

ES6 模块输入的变量counter是"活"的，完全反映其所在模块lib.js内部的变化。再看上一章export一节中出现过的例子：

// m1.js export var foo = 'bar'; setTimeout(() => foo = 'baz', 500); // m2.js import {foo} from './m1.js'; console.log(foo); setTimeout(() => console.log(foo), 500);

m1.js的变量foo刚加载时等于bar，500 毫秒后变为baz。执行m2.js验证它能否读到这个变化：

$ babel-node m2.js bar baz

这证明 ES6 模块不会缓存运行结果，而是动态地去被加载的模块取值，变量总是绑定其所在的模块。

输入接口是只读的

由于 ES6 输入的模块变量只是"符号连接"，所以这个变量是只读的，对它重新赋值会报错：

// lib.js export let obj = {}; // main.js import { obj } from './lib'; obj.prop = 123; // OK obj = {}; // TypeError

main.js可以对obj添加属性，但重新赋值会报错——变量obj指向的地址是只读的，这好比main.js创造了一个名为obj的const变量。这一规则也呼应了上一章 docs/module.md 中"import命令输入的变量都是只读的"的语法约束。

export 输出的是同一个实例

export通过接口输出的是同一个值，不同脚本加载这个接口，得到的都是同样的实例：

// mod.js function C() { this.sum = 0; this.add = function () { this.sum += 1; }; this.show = function () { console.log(this.sum); }; } export let c = new C();

mod.js输出的是一个C的实例，多个脚本加载它得到同一个实例：

// x.js import {c} from './mod'; c.add(); // y.js import {c} from './mod'; c.show(); // main.js import './x'; import './y';

执行main.js，输出的是1：

$ babel-node main.js 1

这证明了x.js和y.js加载的都是C的同一个实例。

Node.js 的模块加载方法

概述：.mjs、type 字段与 .cjs

JavaScript 现在有两种模块：ES6 模块（简称ESM）和 CommonJS 模块（简称CJS）。CommonJS 模块是 Node.js 专用的，与 ES6 模块不兼容。语法上两者最明显的差异是：CommonJS 使用require()和module.exports，ES6 模块使用import和export。

它们采用不同的加载方案。从 Node.js v13.2 版本开始，Node.js 已经默认打开了 ES6 模块支持。Node.js 要求 ES6 模块采用.mjs后缀名——只要脚本文件里使用import或export命令，就必须采用.mjs后缀。Node.js 遇到.mjs文件就认定它是 ES6 模块，默认启用严格模式，不必在模块文件顶部指定"use strict"。

如果不希望把后缀名改成.mjs，可以在项目的package.json中指定type字段为module：

{ "type": "module" }

设置以后，该项目的 JS 脚本就被解释成 ES6 模块：

# 解释成 ES6 模块 $ node my-app.js

如果这时还要使用 CommonJS 模块，则需要把 CommonJS 脚本的后缀名都改成.cjs。如果没有type字段，或者type字段为commonjs，则.js脚本会被解释成 CommonJS 模块。

总结为一句话：.mjs文件总是以 ES6 模块加载，.cjs文件总是以 CommonJS 模块加载，.js文件的加载方式取决于package.json里type字段的设置。

注意，ES6 模块与 CommonJS 模块尽量不要混用：require命令不能加载.mjs文件（会报错），只有import命令才可以加载.mjs文件；反过来，.mjs文件里也不能使用require命令，必须使用import。

package.json 的 main 字段

package.json有两个字段可以指定模块的入口文件：main和exports。比较简单的模块可以只使用main字段，指定模块加载的入口文件：

// ./node_modules/es-module-package/package.json { "type": "module", "main": "./src/index.js" }

上面配置指定项目的入口脚本为./src/index.js，其格式为 ES6 模块。如果没有type字段，index.js就会被解释为 CommonJS 模块。然后import命令就可以加载这个模块：

// ./my-app.mjs import { something } from 'es-module-package'; // 实际加载的是 ./node_modules/es-module-package/src/index.js

运行该脚本后，Node.js 会到./node_modules目录下寻找es-module-package模块，并根据其package.json的main字段执行入口文件。此时如果改用 CommonJS 的require()去加载es-module-package会报错，因为 CommonJS 模块不能处理export命令。

package.json 的 exports 字段

exports字段的优先级高于main字段，它有多种用法。

（1）子目录别名

exports字段可以指定脚本或子目录的别名：

// ./node_modules/es-module-package/package.json { "exports": { "./submodule": "./src/submodule.js" } }

上面代码把src/submodule.js别名为submodule，然后就可以从别名加载这个文件：

import submodule from 'es-module-package/submodule'; // 加载 ./node_modules/es-module-package/src/submodule.js

子目录也可以整体指定别名：

// ./node_modules/es-module-package/package.json { "exports": { "./features/": "./src/features/" } } import feature from 'es-module-package/features/x.js'; // 加载 ./node_modules/es-module-package/src/features/x.js

如果没有指定别名，就不能用"模块+脚本名"这种形式加载脚本：

// 报错 import submodule from 'es-module-package/private-module.js'; // 不报错 import submodule from './node_modules/es-module-package/private-module.js';

（2）main 的别名

exports字段的别名如果是.，就代表模块的主入口，优先级高于main字段，并且可以直接简写成exports字段的值：

{ "exports": { ".": "./main.js" } } // 等同于 { "exports": "./main.js" }

由于exports字段只有支持 ES6 的 Node.js 才认识，所以可以搭配main字段来兼容旧版本的 Node.js：

{ "main": "./main-legacy.cjs", "exports": { ".": "./main-modern.cjs" } }

上面配置中，老版本 Node.js（不支持 ES6 模块）的入口文件是main-legacy.cjs，新版本 Node.js 的入口文件是main-modern.cjs。

（3）条件加载

利用.这个别名，可以为 ES6 模块和 CommonJS 指定不同的入口：

{ "type": "module", "exports": { ".": { "require": "./main.cjs", "default": "./main.js" } } }

别名.的require条件指定require()命令的入口文件（即 CommonJS 的入口），default条件指定其他情况的入口（即 ES6 的入口）。上面的写法可以简写如下：

{ "exports": { "require": "./main.cjs", "default": "./main.js" } }

注意，如果同时还有其他别名，就不能采用简写，否则会报错：

{ // 报错 "exports": { "./feature": "./lib/feature.js", "require": "./main.cjs", "default": "./main.js" } }

CommonJS 模块加载 ES6 模块

CommonJS 的require()命令不能加载 ES6 模块（会报错），只能使用import()这个方法：

(async () => { await import('./my-app.mjs'); })();

上面代码可以在 CommonJS 模块中运行。require()不支持 ES6 模块的一个原因是：它是同步加载，而 ES6 模块内部可以使用顶层await命令，导致无法被同步加载。

ES6 模块加载 CommonJS 模块

ES6 模块的import命令可以加载 CommonJS 模块，但只能整体加载，不能只加载单一的输出项：

// 正确 import packageMain from 'commonjs-package'; // 报错 import { method } from 'commonjs-package';

这是因为 ES6 模块需要支持静态代码分析，而 CommonJS 模块的输出接口是module.exports，是一个对象，无法被静态分析，所以只能整体加载。要加载单一的输出项，可以写成下面这样：

import packageMain from 'commonjs-package'; const { method } = packageMain;

还有一种变通的加载方法，就是使用 Node.js 内置的module.createRequire()方法：

// cjs.cjs module.exports = 'cjs'; // esm.mjs import { createRequire } from 'module'; const require = createRequire(import.meta.url); const cjs = require('./cjs.cjs'); cjs === 'cjs'; // true

ES6 模块通过module.createRequire()方法可以加载 CommonJS 模块。但这种写法等于将 ES6 和 CommonJS 混在一起了，因此不建议使用。

同时支持两种格式的模块

一个模块同时支持 CommonJS 和 ES6 两种格式也很容易。如果原始模块是 ES6 格式，需要给出一个整体输出接口（比如export default obj），使 CommonJS 可以用import()加载。如果原始模块是 CommonJS 格式，可以加一个包装层：

import cjsModule from '../index.js'; export const foo = cjsModule.foo;

上面代码先整体输入 CommonJS 模块，再根据需要输出具名接口。可以将这个文件的后缀名改为.mjs，或者把它放在一个子目录，再在这个子目录里放一个单独的package.json，指明{ type: "module" }。

另一种做法是在package.json的exports字段指明两种格式各自的加载入口：

"exports": { "require": "./index.js", "import": "./esm/wrapper.js" }

上面代码指定require()和import加载该模块时，会自动切换到不一样的入口文件。

Node.js 的内置模块

Node.js 的内置模块可以整体加载，也可以加载指定的输出项：

// 整体加载 import EventEmitter from 'events'; const e = new EventEmitter(); // 加载指定的输出项 import { readFile } from 'fs'; readFile('./foo.txt', (err, source) => { if (err) { console.error(err); } else { console.log(source); } });

加载路径

ES6 模块的加载路径必须给出脚本的完整路径，不能省略脚本的后缀名。import命令和package.json的main字段如果省略脚本后缀名，会报错：

// ES6 模块中将报错 import { something } from './index';

为了与浏览器的import加载规则相同，Node.js 的.mjs文件支持 URL 路径：

import './foo.mjs?query=1'; // 加载 ./foo 传入参数 ?query=1

脚本路径带有参数?query=1时，Node 会按 URL 规则解读。同一个脚本只要参数不同，就会被加载多次，并保存成不同的缓存。因此只要文件名中含有:、%、#、?等特殊字符，最好对这些字符进行转义。

目前，Node.js 的import命令只支持加载本地模块（file:协议）和data:协议，不支持加载远程模块。另外，脚本路径只支持相对路径，不支持绝对路径（即以/或//开头的路径）。

内部变量

ES6 模块应该是通用的，同一个模块不用修改就可以在浏览器环境和服务器环境使用。为了达到这个目标，Node.js 规定 ES6 模块中不能使用 CommonJS 模块特有的一些内部变量。

首先就是this关键字：ES6 模块中顶层的this指向undefined；CommonJS 模块的顶层this指向当前模块，这是两者的一个重大差异。其次，以下这些顶层变量在 ES6 模块中都不存在：

• arguments
• require
• module
• exports
• __filename
• __dirname

循环加载

什么是循环加载

"循环加载"（circular dependency）指的是：a脚本的执行依赖b脚本，而b脚本的执行又依赖a脚本：

// a.js var b = require('b'); // b.js var a = require('a');

通常，循环加载表示存在强耦合，如果处理不好还可能导致递归加载，使程序无法执行，因此应该尽量避免。但实际中很难完全避免——尤其是依赖关系复杂的大项目，很容易出现a依赖b、b依赖c、c又依赖a的情况。这意味着模块加载机制必须考虑循环加载的场景。

对于 JavaScript 语言来说，最常见的两种模块格式 CommonJS 和 ES6，处理循环加载的方法不一样，返回的结果也不一样。

CommonJS 模块的加载原理

CommonJS 的一个模块就是一个脚本文件。require命令第一次加载该脚本，就会执行整个脚本，然后在内存中生成一个对象：

{ id: '...', exports: { ... }, loaded: true, ... }

上面就是 Node 内部加载模块后生成的对象：id属性是模块名，exports属性是模块输出的各个接口，loaded属性是布尔值，表示该模块的脚本是否执行完毕（还有其他属性，此处省略）。以后需要用到这个模块时，就会到exports属性上取值。即使再次执行require命令，也不会再次执行该模块，而是从缓存中取值。也就是说，CommonJS 模块无论加载多少次，都只在第一次加载时运行一次，以后再加载就返回第一次运行的结果，除非手动清除系统缓存。

CommonJS 模块的循环加载

CommonJS 模块的重要特性是加载时执行：脚本代码在require的时候就会全部执行。一旦出现某个模块被"循环加载"，就只输出已经执行的部分，还未执行的部分不会输出。

看一个经典的例子。脚本文件a.js代码如下：

exports.done = false; var b = require('./b.js'); console.log('在 a.js 之中，b.done = %j', b.done); exports.done = true; console.log('a.js 执行完毕');

a.js先输出一个done变量，然后加载另一个脚本b.js。注意，此时a.js的代码就停在这里，等待b.js执行完毕再继续。再看b.js的代码：

exports.done = false; var a = require('./a.js'); console.log('在 b.js 之中，a.done = %j', a.done); exports.done = true; console.log('b.js 执行完毕');

b.js执行到第二行就去加载a.js，这时发生了"循环加载"。系统会到a.js模块对应对象的exports属性取值，但a.js还没执行完，只能取回已经执行的部分——目前只有一行：

exports.done = false;

因此对于b.js来说，它从a.js只输入一个变量done，值为false。然后b.js继续往下执行，执行完毕后把执行权交还给a.js，a.js再接着执行直到完毕。写一个脚本main.js验证这个过程：

var a = require('./a.js'); var b = require('./b.js'); console.log('在 main.js 之中, a.done=%j, b.done=%j', a.done, b.done);

执行结果如下：

$ node main.js 在 b.js 之中，a.done = false b.js 执行完毕 在 a.js 之中，b.done = true a.js 执行完毕 在 main.js 之中, a.done=true, b.done=true

上面的输出证明了两件事：一是b.js加载a.js时，a.js只执行了第一行；二是main.js执行到第二行时不会再次执行b.js，而是输出缓存的执行结果（即第四行exports.done = true;）。

总之，CommonJS 输入的是被输出值的拷贝，不是引用。另外，由于 CommonJS 模块遇到循环加载时返回的是当前已执行部分的值，而不是全部代码执行后的值，两者可能有差异，所以输入变量时必须非常小心：

var a = require('a'); // 安全的写法 var foo = require('a').foo; // 危险的写法 exports.good = function (arg) { return a.foo('good', arg); // 使用的是 a.foo 的最新值 }; exports.bad = function (arg) { return foo('bad', arg); // 使用的是一个部分加载时的值 };

如果发生循环加载，require('a').foo的值很可能在后面被改写，改用require('a')会更保险。

ES6 模块的循环加载

ES6 处理循环加载与 CommonJS 有本质不同。ES6 模块是动态引用：如果使用import从一个模块加载变量，那些变量不会被缓存，而是成为指向被加载模块的引用，需要开发者自己保证真正取值时能取到值。看下面这个例子：

// a.mjs import {bar} from './b'; console.log('a.mjs'); console.log(bar); export let foo = 'foo'; // b.mjs import {foo} from './a'; console.log('b.mjs'); console.log(foo); export let bar = 'bar';

a.mjs加载b.mjs，b.mjs又加载a.mjs，构成循环加载。执行a.mjs：

$ node --experimental-modules a.mjs b.mjs ReferenceError: foo is not defined

执行a.mjs后报错foo未定义，为什么？逐行分析 ES6 循环加载的处理过程：

1. 执行a.mjs后，引擎发现它加载了b.mjs，因此会优先执行b.mjs，再执行a.mjs；
2. 执行b.mjs时，已知它从a.mjs输入了foo接口，此时不会去执行a.mjs，而是认为这个接口已经存在，继续往下执行；
3. 执行到第三行console.log(foo)时，才发现这个接口根本没定义，因此报错。

解决方法是让b.mjs运行时foo已经有定义，这可以通过把foo写成函数来解决（函数声明具有提升作用）：

// a.mjs import {bar} from './b'; console.log('a.mjs'); console.log(bar()); function foo() { return 'foo' } export {foo}; // b.mjs import {foo} from './a'; console.log('b.mjs'); console.log(foo()); function bar() { return 'bar' } export {bar};

再执行a.mjs就得到预期结果：

$ node --experimental-modules a.mjs b.mjs foo a.mjs bar

这是因为函数声明具有提升作用：在执行import {bar} from './b'时，函数foo就已经有定义了，所以b.mjs加载时不会报错。这也意味着，如果把函数foo改写成函数表达式，就会再次报错：

// a.mjs import {bar} from './b'; console.log('a.mjs'); console.log(bar()); const foo = () => 'foo'; export {foo};

第四行改成了函数表达式，不具有提升作用，执行就会报错。

再看 ES6 模块加载器 SystemJS 给出的一个经典例子：

// even.js import { odd } from './odd' export var counter = 0; export function even(n) { counter++; return n === 0 || odd(n - 1); } // odd.js import { even } from './even'; export function odd(n) { return n !== 0 && even(n - 1); }

even.js里的函数even有一个参数n，只要不等于 0 就会减 1，传入加载的odd()；odd.js也会做类似操作。运行结果如下：

$ babel-node > import * as m from './even.js'; > m.even(10); true > m.counter 6 > m.even(20) true > m.counter 17

参数n从 10 变为 0 的过程中，even()一共执行 6 次，所以counter等于 6；第二次调用even()时参数从 20 变为 0，even()执行 11 次，加上前面的 6 次，counter等于 17。

这个例子如果改写成 CommonJS 就根本无法执行，会报错：

// even.js var odd = require('./odd'); var counter = 0; exports.counter = counter; exports.even = function (n) { counter++; return n == 0 || odd(n - 1); } // odd.js var even = require('./even').even; module.exports = function (n) { return n != 0 && even(n - 1); }

even.js加载odd.js，而odd.js又去加载even.js，形成循环加载。执行引擎会输出even.js已经执行的部分（此时不存在任何结果），所以在odd.js中变量even等于undefined，后面调用even(n - 1)就会报错：

$ node > var m = require('./even'); > m.even(10) TypeError: even is not a function

小结：ESM 与 CJS 加载机制对照

浏览器端通过<script type="module">（配合defer/async）加载 ESM；Node.js 端则通过.mjs后缀、package.json的type/main/exports字段来区分与配置两种模块体系。理解"值的拷贝 vs 值的引用""编译时 vs 运行时"这两条主线，就能把握 ESM 与 CJS 在加载实现上的全部差异，进而在实际项目中正确地组织模块、规避循环加载陷阱。相关语法层面的完整讲解可继续查阅本书上一章 docs/module.md，全书章节索引见 SUMMARY.md。

【免费下载链接】es6tutorial《ECMAScript 6入门》是一本开源的 JavaScript 语言教程，全面介绍 ECMAScript 6 新增的语法特性。项目地址: https://gitcode.com/gh_mirrors/es/es6tutorial