摘要：模塊演化簡史從屬于筆者的開發(fā)基礎(chǔ)與工程實(shí)踐。首個(gè)采樣該設(shè)計(jì)模式的界面庫當(dāng)屬，其是創(chuàng)建于年。允許我們定義模塊，并且在顯式地聲明其依賴模塊而由框架完成自動(dòng)注入。而最后的模塊化規(guī)范定義于年正式發(fā)布，也就是被命名為。

JavaScript 模塊演化簡史 從屬于筆者的 Web 開發(fā)基礎(chǔ)與工程實(shí)踐。本文主要總結(jié)自 The Evolution of JavaScript Modularity、Native ECMAScript modules - the first overview、Native ECMAScript modules: the new features and differences from Webpack modules 等 JavaScript 語法學(xué)習(xí)資料索引 中注明的文章，更多深度思考參閱 2016-我的前端之路:工具化與工程化。

當(dāng)年 Brendan Eich 草創(chuàng) JavaScript 之際，他應(yīng)該無法想象 JavaScript 在未來二十年內(nèi)發(fā)揮的巨大作用；同樣作為廣為詬病的過于隨意的語言，缺乏強(qiáng)有力的模塊化解決方案一直是 JavaScript 的缺陷之一。早期的 JavaScript 往往作為嵌入到 HTML 頁面中的用于控制動(dòng)畫與簡單的用戶交互的腳本語言，我們習(xí)慣于將其直接嵌入到 script 標(biāo)簽中：

不過隨著單頁應(yīng)用與富客戶端的流行，不斷增長的代碼庫也急需合理的代碼分割與依賴管理的解決方案，這也就是我們在軟件工程領(lǐng)域所熟悉的模塊化（Modularity）。所謂模塊化主要是解決代碼分割、作用域隔離、模塊之間的依賴管理以及發(fā)布到生產(chǎn)環(huán)境時(shí)的自動(dòng)化打包與處理等多個(gè)方面。二十年間流行過的 JavaScript 模塊化解決方案包括但不限于直接聲明依賴（Directly Defined Dependences）、命名空間（Namespace Pattern）、模塊模式（Module Pattern）、依賴分離定義（Detached Dependency Definitions）、沙盒（Sandbox）、依賴注入（Dependency Injection）、CommonJS、AMD、UMD、標(biāo)簽化模塊（Labeled Modules）、YModules、ES 2015 Modules。
在早期的 Web 開發(fā)中，所有的嵌入到網(wǎng)頁內(nèi)的 JavaScript 對(duì)象都會(huì)使用全局的 window 對(duì)象來存放未使用 var 定義的變量。大概在上世紀(jì)末，JavaScript 多用于解決簡單的任務(wù)，這也就意味著我們只需編寫少量的 JavaScript 代碼；不過隨著代碼庫的線性增長，我們首先會(huì)碰到的就是所謂命名沖突（Name Collisions）困境：

// file greeting.js
var helloInLang = {
    en: "Hello world!",
    es: "?Hola mundo!",
    ru: "Привет мир!"
};

function writeHello(lang) {
    document.write(helloInLang[lang]);
}

// file hello.js
function writeHello() {
    document.write("The script is broken");
}

當(dāng)我們在頁面內(nèi)同時(shí)引入這兩個(gè) JavaScript 腳本文件時(shí)，顯而易見兩個(gè)文件中定義的 writeHello 函數(shù)起了沖突，最后調(diào)用的函數(shù)取決于我們引入的先后順序。此外在大型應(yīng)用中，我們不可能將所有的代碼寫入到單個(gè) JavaScript 文件中；我們也不可能手動(dòng)地在 HTML 文件中引入全部的腳本文件，特別是此時(shí)還存在著模塊間依賴的問題，相信很多開發(fā)者都會(huì)遇到 jQuery 尚未定義這樣的問題。不過物極必反，過度碎片化的模塊同樣會(huì)帶來性能的損耗與包體尺寸的增大，這包括了模塊加載、模塊解析、因?yàn)?Webpack 等打包工具包裹模塊時(shí)封裝的過多 IIFE 函數(shù)導(dǎo)致的 JavaScript 引擎優(yōu)化失敗等。譬如我們的源碼如下：

// index.js
var total = 0
total += require("./module_0")
total += require("./module_1")
total += require("./module_2")
// etc.
console.log(total)

// module_0.js
module.exports = 0

// module_1.js
module.exports = 1

經(jīng)過 Browserify 打包之后的代碼變成了如下式樣：

(function e(t,n,r){function s(o,u){if(!n[o]){if(!t[o]){var a=typeof require=="function"&&require;if(!u&&a)return a(o,!0);if(i)return i(o,!0);var f=new Error("Cannot find module ""+o+""");throw f.code="MODULE_NOT_FOUND",f}var l=n[o]={exports:{}};t[o][0].call(l.exports,function(e){var n=t[o][1][e];return s(n?n:e)},l,l.exports,e,t,n,r)}return n[o].exports}var i=typeof require=="function"&&require;for(var o=0;o
我們分別測試 100、1000 與 5000 模塊，可以發(fā)現(xiàn)隨著模塊數(shù)目的增長最后的包體大小并非線性增長：

命名空間模式
命名空間模式始于 2002 年，顧名思義我們可以使用特殊的約定命名。譬如我們可以為某個(gè)模塊內(nèi)的變量統(tǒng)一添加 myApp_ 前綴，譬如 myApp_address，myApp_validateUser() 等等。同樣，我們也可以將函數(shù)賦值給模塊內(nèi)的變量或者對(duì)象的屬性，從而可以使得可以像 document.write() 這樣在子命名空間下定義函數(shù)而避免沖突。首個(gè)采樣該設(shè)計(jì)模式的界面庫當(dāng)屬 Bindows，其是 Erik Arvidsson 創(chuàng)建于 2002 年。他沒有簡單地為自定義函數(shù)或者對(duì)象添加命名前綴，而是將所有的 Bindows 當(dāng)中的數(shù)據(jù)與邏輯代碼封裝于某個(gè)全局對(duì)象內(nèi)，從而避免所謂的全局作用域污染。命名空間模式的設(shè)計(jì)思想如下所示：
// file app.js
var app = {};

// file greeting.js
app.helloInLang = {
    en: "Hello world!",
    es: "?Hola mundo!",
    ru: "Привет мир!"
};

// file hello.js
app.writeHello = function (lang) {
    document.write(app.helloInLang[lang]);
};
我們可以發(fā)現(xiàn)自定義代碼中的所有數(shù)據(jù)對(duì)象與函數(shù)都?xì)w屬于全局對(duì)象 app，不過顯而易見這種方式對(duì)于大型多人協(xié)同項(xiàng)目的可維護(hù)性還是較差，并且沒有解決模塊間依賴管理的問題。另外有時(shí)候我們需要處理一些自動(dòng)執(zhí)行的 Pollyfill 性質(zhì)的代碼，就需要將模塊包裹在自調(diào)用的函數(shù)中，譬如在某個(gè)大型應(yīng)用中，我們的代碼可能會(huì)切分為如下幾個(gè)模塊：
// polyfill-vendor.js
(function(){
    // polyfills-vendor code
}());

// module1.js
function module1(params){
    // module1 code
    return module1;
}

// module3.js
function module3(params){
    this.a = params.a;
}

module3.prototype.getA = function(){
    return this.a;
};

// app.js
var APP = {};

if(isModule1Needed){
    APP.module1 = module1({param1:1});
}

APP.module3 = new module3({a: 42});
那么在引入的時(shí)候我們需要手動(dòng)地按照模塊間依賴順序引入進(jìn)來：





不過這種方式對(duì)于模塊間通信也是個(gè)麻煩。命名空間模式算是如今 JavaScript 領(lǐng)域最為著名的模式之一，而在 Bindows 之后 Dojo(2005)，YUI(2005) 這些優(yōu)秀的界面框架也是承襲了這種思想。
依賴注入
Martin Fowler 于 2004 年提出了依賴注入（Dependency Injection）的概念，其主要用于 Java 中的組件內(nèi)通信；以 Spring 為代表的一系列支持依賴注入與控制反轉(zhuǎn)的框架將這種設(shè)計(jì)模式發(fā)揚(yáng)光大，并且成為了 Java 服務(wù)端開發(fā)的標(biāo)準(zhǔn)模式之一。依賴注入的核心思想在于某個(gè)模塊不需要手動(dòng)地初始化某個(gè)依賴對(duì)象，而只需要聲明該依賴并由外部框架自動(dòng)實(shí)例化該對(duì)象實(shí)現(xiàn)并且傳遞到模塊內(nèi)。而五年之后的 2009 年 Misko Hevery 開始設(shè)計(jì)新的 JavaScript 框架，并且使用了依賴注入作為其組件間通信的核心機(jī)制。這個(gè)框架就是引領(lǐng)一時(shí)風(fēng)騷，甚至于說是現(xiàn)代 Web 開發(fā)先驅(qū)之一的 Angular。Angular 允許我們定義模塊，并且在顯式地聲明其依賴模塊而由框架完成自動(dòng)注入。其核心思想如下所示：
// file greeting.js
angular.module("greeter", [])
    .value("greeting", {
        helloInLang: {
            en: "Hello world!",
            es: "?Hola mundo!",
            ru: "Привет мир!"
        },

        sayHello: function(lang) {
            return this.helloInLang[lang];
        }
    });

// file app.js
angular.module("app", ["greeter"])
    .controller("GreetingController", ["$scope", "greeting", function($scope, greeting) {
        $scope.phrase = greeting.sayHello("en");
    }]);
之后在 Angular 2 與 Slot 之中依賴注入仍是核心機(jī)制之一，這也是 Angular 一系的更多的被視為大而全的框架而不是小而美的庫的原因之一。
CommonJS
在 Node.js 橫空出世之前，就已經(jīng)有很多將運(yùn)行于客戶端瀏覽器中的 JavaScript 遷移運(yùn)行到服務(wù)端的框架；不過由于缺乏合適的規(guī)范，也沒有提供統(tǒng)一的與操作系統(tǒng)及運(yùn)行環(huán)境交互的接口，這些框架并未流行開來。2009 年時(shí) Mozilla 的雇員 Kevin Dangoor 發(fā)表了博客討論服務(wù)端 JavaScript 代碼面臨的困境，號(hào)召所有有志于規(guī)范服務(wù)端 JavaScript 接口的志同道合的開發(fā)者協(xié)同討論，群策群力，最終形成了 ServerJS 規(guī)范；一年之后 ServerJS 重命名為 CommonJS。后來 CommonJS 內(nèi)的模塊規(guī)范成為了 Node.js 的標(biāo)準(zhǔn)實(shí)現(xiàn)規(guī)范，其基本語法為 var commonjs = require("./commonjs");，核心設(shè)計(jì)模式如下所示：
// file greeting.js
var helloInLang = {
    en: "Hello world!",
    es: "?Hola mundo!",
    ru: "Привет мир!"
};

var sayHello = function (lang) {
    return helloInLang[lang];
}

module.exports.sayHello = sayHello;

// file hello.js
var sayHello = require("./lib/greeting").sayHello;
var phrase = sayHello("en");
console.log(phrase);
該模塊實(shí)現(xiàn)方案主要包含 require 與 module 這兩個(gè)關(guān)鍵字，其允許某個(gè)模塊對(duì)外暴露部分接口并且由其他模塊導(dǎo)入使用。在 Node.js 中我們通過內(nèi)建輔助函數(shù)來使用 CommonJS 的導(dǎo)入導(dǎo)出功能，而在其他 JavaScript 引擎中我們可以將其包裹為如下形式：
(function (exports, require, module, __filename, __dirname) {
    // ...
    // Your code injects here!
    // ...
});
CommonJS 規(guī)范本身只是定義了不同環(huán)境下支持模塊交互性的最小化原則，其具備極大的可擴(kuò)展性。Node.js 中就對(duì) require 函數(shù)添加了 main 屬性，該屬性在執(zhí)行模塊所屬文件時(shí)指向 module 對(duì)象。Babel 在實(shí)現(xiàn) ES2015 Modules 的轉(zhuǎn)義時(shí)也擴(kuò)展了 require 關(guān)鍵字：
export default something;
Babel 將此類型的導(dǎo)出轉(zhuǎn)化為了 CommonJS 模塊，簡單而言形式如下：
export.default = something;
Webpack 打包工具也使用了很多擴(kuò)展，譬如 require.ensure、require.cache、require.context 等等。CommonJS 算是目前最流行的模塊格式，我們不僅可以在 Node.js 中使用，還可以通過 Browserify 與 Webpack 這樣的打包工具將代碼打包到客戶端運(yùn)行。另外我們需要注意的是，Node.js 中的模塊在加載之后是以單例化運(yùn)行，并且遵循值傳遞原則：
// obj.js
module.exports = {
    num:1
}

// primitive.js
module.exports = 1;

// modifier.js
var number = require("./primitive");
var obj = require("./obj");

number = 2;
obj.num = 2;

console.log(number);
console.log(obj);

// main.js
console.log(require("./primitive"));
console.log(require("./obj"));

require("./modifier.js")

console.log(require("./primitive"));
console.log(require("./obj"));

// 執(zhí)行結(jié)果
1
{ num: 1 }
2
{ num: 2 }
1
{ num: 2 }
AMD
就在 CommonJS 規(guī)范火熱討論的同時(shí)，很多開發(fā)者也關(guān)注于如何實(shí)現(xiàn)模塊的異步加載。Web 應(yīng)用的性能優(yōu)化一直是前端工程實(shí)踐中不可避免的問題，而模塊的異步加載以及預(yù)加載等機(jī)制能有效地優(yōu)化 Web 應(yīng)用的加載速度。Mozilla 的另一位雇員 James Burke 是討論組的活躍成員，他在 Dojo 1.7 版本中引入了異步模塊機(jī)制，并且在 2009 年開發(fā)了 require.js 框架。James 的核心思想在于不應(yīng)該以同步方式加載模塊，而應(yīng)該充分利用瀏覽器的并發(fā)加載能力；James 按照其設(shè)計(jì)理念開發(fā)出的模塊工具就是 AMD（Asynchronous Module Definition），其基本形式如下：
define(["amd-module", "../file"], function(amdModule, file) {
    require(["big-module/big/file"], function(big) {
        var stuff = require("../my/stuff");
    });
});
而將我們上述使用的例子改寫為 AMD 模式應(yīng)當(dāng)如下所示：
// file lib/greeting.js
define(function() {
    var helloInLang = {
        en: "Hello world!",
        es: "?Hola mundo!",
        ru: "Привет мир!"
    };

    return {
        sayHello: function (lang) {
            return helloInLang[lang];
        }
    };
});

// file hello.js
define(["./lib/greeting"], function(greeting) {
    var phrase = greeting.sayHello("en");
    document.write(phrase);
});
hello.js 作為整個(gè)應(yīng)用的入口模塊，我們使用 define 關(guān)鍵字聲明了該模塊以及外部依賴；當(dāng)我們執(zhí)行該模塊代碼時(shí)，也就是執(zhí)行 define 函數(shù)的第二個(gè)參數(shù)中定義的函數(shù)功能，其會(huì)在框架將所有的其他依賴模塊加載完畢后被執(zhí)行。這種延遲代碼執(zhí)行的技術(shù)也就保證了依賴的并發(fā)加載。從我個(gè)人而言，AMD 及其相關(guān)技術(shù)對(duì)于前端開發(fā)的工程化進(jìn)步有著非常積極的意義，不過隨著以 npm 為主導(dǎo)的依賴管理機(jī)制的統(tǒng)一，越來越多的開發(fā)者放棄了使用 AMD 模式。
UMD
AMD 與 CommonJS 雖然師出同源，但還是分道揚(yáng)鑣，關(guān)注于代碼異步加載與最小化入口模塊的開發(fā)者將目光投注于 AMD；而隨著 Node.js 以及 Browserify 的流行，越來越多的開發(fā)者也接受了 CommonJS 規(guī)范。令人扼腕嘆息的是，符合 AMD 規(guī)范的模塊并不能直接運(yùn)行于實(shí)踐了 CommonJS 模塊規(guī)范的環(huán)境中，符合 CommonJS 規(guī)范的模塊也不能由 AMD 進(jìn)行異步加載，整個(gè) JavaScript 生態(tài)圈貌似分崩離析。2011 年中，UMD，也就是 Universal Module Definition 規(guī)范正是為了彌合這種不一致性應(yīng)運(yùn)而出，其允許在環(huán)境中同時(shí)使用 AMD 與 CommonJS 規(guī)范。Q 算是 UMD 的首個(gè)規(guī)范實(shí)現(xiàn)，其能同時(shí)運(yùn)行于瀏覽器環(huán)境（以腳本標(biāo)簽形式嵌入）與服務(wù)端的 Node.js 或者 Narwhal（CommonJS 模塊）環(huán)境中；稍后，James 也為 Q 添加了對(duì)于 AMD 的支持。我們將上述例子中的 greeting.js 改寫為同時(shí)支持 CommonJS 與 AMD 規(guī)范的模塊：
(function(define) {
    define(function () {
        var helloInLang = {
            en: "Hello world!",
            es: "?Hola mundo!",
            ru: "Привет мир!"
        };

        return {
            sayHello: function (lang) {
                return helloInLang[lang];
            }
        };
    });
}(
    typeof module === "object" && module.exports && typeof define !== "function" ?
    function (factory) { module.exports = factory(); } :
    define
));
該模式的核心思想在于所謂的 IIFE（Immediately Invoked Function Expression），該函數(shù)會(huì)根據(jù)環(huán)境來判斷需要的參數(shù)類別，譬如在 CommonJS 環(huán)境下上述代碼會(huì)以如下方式執(zhí)行：
function (factory) {
    module.exports = factory();
} 
而如果是在 AMD 模塊規(guī)范下，函數(shù)的參數(shù)就變成了 define。正是因?yàn)檫@種運(yùn)行時(shí)的靈活性是我們能夠?qū)⑼环荽a運(yùn)行于不同的環(huán)境中。
ES2015 Modules
JavaScript 模塊規(guī)范領(lǐng)域群雄逐鹿，各領(lǐng)風(fēng)騷，作為 ECMAScript 標(biāo)準(zhǔn)的起草者 TC39 委員會(huì)自然也不能置身事外。ES2015 Modules 規(guī)范始于 2010 年，主要由 Dave Herman 主導(dǎo)；隨后的五年中 David 還參與了 asm.js，emscription，servo，等多個(gè)重大的開源項(xiàng)目，也使得 ES2015 Modules 的設(shè)計(jì)能夠從多方面進(jìn)行考慮與權(quán)衡。而最后的模塊化規(guī)范定義于 2015 年正式發(fā)布，也就是被命名為 ES2015 Modules。我們上述的例子改寫為 ES2015 Modules 規(guī)范如下所示：
// file lib/greeting.js
const helloInLang = {
    en: "Hello world!",
    es: "?Hola mundo!",
    ru: "Привет мир!"
};

export const greeting = {
    sayHello: function (lang) {
        return helloInLang[lang];
    }
};

// file hello.js
import { greeting } from "./lib/greeting";
const phrase = greeting.sayHello("en");
document.write(phrase);
ES2015 Modules 中主要的關(guān)鍵字就是 import 與 export，前者負(fù)責(zé)導(dǎo)入模塊而后者負(fù)責(zé)導(dǎo)出模塊。完整的導(dǎo)出語法如下所示：
// default exports
export default 42;
export default {};
export default [];
export default foo;
export default function () {}
export default class {}
export default function foo () {}
export default class foo {}

// variables exports
export var foo = 1;
export var foo = function () {};
export var bar; // lazy initialization
export let foo = 2;
export let bar; // lazy initialization
export const foo = 3;
export function foo () {}
export class foo {}

// named exports
export {foo};
export {foo, bar};
export {foo as bar};
export {foo as default};
export {foo as default, bar};

// exports from
export * from "foo";
export {foo} from "foo";
export {foo, bar} from "foo";
export {foo as bar} from "foo";
export {foo as default} from "foo";
export {foo as default, bar} from "foo";
export {default} from "foo";
export {default as foo} from "foo";
相對(duì)應(yīng)的完整的支持的導(dǎo)入方式如下所示：
// default imports
import foo from "foo";
import {default as foo} from "foo";

// named imports
import {bar} from "foo";
import {bar, baz} from "foo";
import {bar as baz} from "foo";
import {bar as baz, xyz} from "foo";

// glob imports
import * as foo from "foo";

// mixing imports
import foo, {baz as xyz} from "foo";
import * as bar, {baz as xyz} from "foo";
import foo, * as bar, {baz as xyz} from "foo";
ES2015 Modules 作為 JavaScript 官方標(biāo)準(zhǔn)，日漸成為了開發(fā)者的主流選擇。雖然我們目前還不能直接保證在所有環(huán)境（特別是舊版本瀏覽器）中使用該規(guī)范，但是通過 Babel 等轉(zhuǎn)化工具能幫我們自動(dòng)處理向下兼容。此外 ES2015 Modules 還是有些許被詬病的地方，譬如導(dǎo)入語句只能作為模塊頂層的語句出現(xiàn)，不能出現(xiàn)在 function 里面或是 if 里面：
if(Math.random()>0.5){
  import "./module1.js"; // SyntaxError: Unexpected keyword "import"
}
const import2 = (import "./main2.js"); // SyntaxError
try{
  import "./module3.js"; // SyntaxError: Unexpected keyword "import"
}catch(err){
  console.error(err);
}
const moduleNumber = 4;

import module4 from `module${moduleNumber}`; // SyntaxError: Unexpected token
并且 import 語句會(huì)被提升到文件頂部執(zhí)行，也就是說在模塊初始化的時(shí)候所有的 import 都必須已經(jīng)導(dǎo)入完成：
import "./module1.js";

alert("code1");

import module2 from "./module2.js";

alert("code2");

import module3 from "./module3.js";

// 執(zhí)行結(jié)果
module1
module2
module3
code1
code2
并且 import 的模塊名只能是字符串常量，導(dǎo)入的值也是不可變對(duì)象；比如說你不能 import { a } from "./a" 然后給 a 賦值個(gè)其他什么東西。這些設(shè)計(jì)雖然使得靈活性不如 CommonJS 的 require，但卻保證了 ES6 Modules 的依賴關(guān)系是確定（Deterministic）的，和運(yùn)行時(shí)的狀態(tài)無關(guān)，從而也就保證了 ES6 Modules 是可以進(jìn)行可靠的靜態(tài)分析的。對(duì)于主要在服務(wù)端運(yùn)行的 Node 來說，所有的代碼都在本地，按需動(dòng)態(tài) require 即可，但對(duì)于要下發(fā)到客戶端的 Web 代碼而言，要做到高效的按需使用，不能等到代碼執(zhí)行了才知道模塊的依賴，必須要從模塊的靜態(tài)分析入手。這是 ES6 Modules 在設(shè)計(jì)時(shí)的一個(gè)重要考量，也是為什么沒有直接采用 CommonJS。此外我們還需要關(guān)注下的是 ES2015 Modules 在瀏覽器內(nèi)的原生支持情況，盡管我們可以通過 Webpack 等打包工具將應(yīng)用打包為單個(gè)包文件。目前主流瀏覽器中默認(rèn)支持 ES2015 Modules 只有 Safari，而 Firefox 在 54 版本之后允許用戶手動(dòng)啟用該特性。以 Firefox 為例，如果我們在瀏覽器中使用 ES2015 Modules，我們需要聲明入口模塊：

這里的 module 關(guān)鍵字就告訴瀏覽器該腳本中包含了對(duì)于其他腳本的導(dǎo)入語句，需要進(jìn)行預(yù)先處理；不過問題來了，那么 JavaScript 解釋器又該如何判斷某個(gè)文件是否為模塊。社區(qū)也經(jīng)過很多輪的討論，我們可以來看下簡單的例子：



  
    
  
  
  

main.js 的代碼實(shí)現(xiàn)如下：
// main.js
import utils from "./utils.js";

utils.alert(`
  JavaScript modules work in this browser:
  https://blog.whatwg.org/js-modules
`);
待導(dǎo)入的模塊如下：
// utils.js
export default {
    alert: (msg)=>{
        alert(msg);
    }
};
我們可以發(fā)現(xiàn)，在 import 語句中我們提供了 .js 擴(kuò)展名，這也是區(qū)別于打包工具的重要特性之一，往往打包工具中并不需要我們提供擴(kuò)展名。此外，在瀏覽器中進(jìn)行模塊的動(dòng)態(tài)加載，也要求待加載文件具有正確的 MIME 類型。我們常用的正確的模塊地址譬如：
https://example.com/apples.js
http:example.compears.mjs (becomes http://example.com/pears.mjs as step 1 parses with no base URL)
//example.com/bananas
./strawberries.js.cgi
../lychees
/limes.jsx
data:text/javascript,export default ‘grapes’;
blob:https://whatwg.org/d0360e2f-caee-469f-9a2f-87d5b0456f6f
不過筆者覺得有個(gè)不錯(cuò)的特性在于瀏覽器中支持 CORS 協(xié)議，跨域加載其他域中的腳本。在瀏覽器中加載進(jìn)來的模塊與直接加載的腳本的作用域也是不一致的，并且不需要 use strict 聲明其也默認(rèn)處于嚴(yán)格模式下：
var x = 1;

alert(x === window.x);//false
alert(this === undefined);// true
瀏覽器對(duì)于模塊的加載默認(rèn)是異步延遲進(jìn)行的，即模塊腳本的加載并不會(huì)阻塞瀏覽器的解析行為，而是并發(fā)加載并在頁面加載完畢后進(jìn)行解析，也就是所有的模塊腳本具有 defer 屬性。我們也可以為腳本添加 async 屬性，即指明該腳本會(huì)在加載完畢后立刻執(zhí)行。這一點(diǎn)與傳統(tǒng)的非模塊腳本相比很大不同，傳統(tǒng)的腳本會(huì)阻塞瀏覽器解析直到抓取完畢，在抓取之后也會(huì)立刻進(jìn)行執(zhí)行操作。整個(gè)加載流程如下所示：