適讀人群 ：JAVASCRIPT語言精髓與編程實踐》適合於有編程經驗的、想學習和掌握JavaScript的語言實現與擴展知識的開發者。

√ 綠皮書正式版：經過前兩個版本的積累和歷經三年的全面重寫，這本書終於達成技術剖析和用戶體驗的完美契合
√ 廣深鑄就宏篇：論深，本書深究JS之所以然，舉世無可出其右；論廣，本書遍歷語義之細部，看罷再無機理之惑
√ 超語言之思想：萬法歸宗異曲同工，剝去JS外殼，本書居高處辨析語言奧義的技術大局觀，適用於所有編程語言
√ 修煉重在重學：混合App|Node服務端|FaaS雲原生|前端智能化時代，回歸本質重修這門基礎課纔能走得更遠更快

JavaScript 是一門包含多種語言特性的混合範型語言，在面向對像和函數式語言特性方面表現尤為突出，且在 ES6 之後所添加的並行語言特性也極為出色。《JavaScript語言精髓與編程實踐（第3版）》基於 ES6，並涵蓋 ES2019 規範，全面講述 JavaScript 在五個方面的語言特性，以及將這些特性融會如一的方法。本書不但完整解析了 JavaScript 語言，還逐一剖析了相關特性在多個開源項目中的編程實踐與應用，是難得的語言學習參考書。

本書作者在前端開發領域經驗豐富、深耕不輟，一書三版，歷經十餘年。書中對 JavaScript 語言的理解與展望，尤其適合期望精通這門語言的中高級程序員和語言實踐者閱讀。

周愛民( Aimingoo )

南潮( ruff.io )架構師、知名JavaScript專家。從1996年開始涉足商業軟件開發，在軟件開發、軟件工程、團隊建設以及部門管理方面經驗豐富，曾任zfb(中國)公司業務架構師、盛大網絡平臺架構師、豌豆莢架構師等職。著有《Delphi源代碼分析》《大道至簡》《大道至易》《程序原本》《動態函數式語言精髓》《 我的架構思想》《 JavaScript語言精髓與編程實踐》等圖書。

第一次接觸愛民這本書的第1版是在2008年下半年，那時候學習前端時間不長，對很多知識點理解得也不深入，閱讀這本書時帶給我很多欣喜，同時對我的思維方式影響也很大。看完書後，明顯感覺自己對JavaScript的理解有了質的飛躍，對我前期的學習幫助非常大，建議希望提升自己JavaScript水平的小伙伴閱讀這本書(結合ECMAScript標準規範閱讀，效果會更好)。
李成銀( welefen)，Think JS框架作者

第 1 章 二十年來的 JavaScript 1

1.1 網頁中的代碼1

1.1.1 新鮮的玩意兒 1

1.1.2 寫在網頁中的第一段代碼 2

1.1.3 最初的價值 3

1.2 用 JavaScript 來寫瀏覽器上的應用5

1.2.2 Flash 的一席之地 7

1.2.3 RWC 與 RIA 之爭 8

1.3 沒有框架與庫的語言能怎樣發展呢 10

1.3.1 做一個框架10

1.3.2 重寫框架的語言層 .13

1.3.3 富瀏覽器端開發（RWC）與 AJAX14

1.4 語言的進化16

1.4.1 Qomo 的重生16

1.4.2 QoBean 是對語言的重新組織 .17

1.4.3 JavaScript 作為一門語言的進化18

1.5 大型繫統開發20

1.5.1 框架與架構是不同的 .20

1.5.2 大型繫統與分布式的環境 21

1.5.3 劃時代的 ES6.23

1.6 為 JavaScript 正名 24

1.6.1 JavaScript .25

1.6.1.1 Core JavaScript26

1.6.1.2 SpiderMonkey JavaScript 27

1.6.1.3 JScript .27

1.6.2 ECMAScript 28

1.7 JavaScript 的應用環境29

1.7.1 宿主環境 30

1.7.2 外殼程序

第 2 章 JavaScript 的語法 36
2.1 語法綜述 36
2.1.1 標識符所綁定的語義.37
2.1.2 識別語法錯誤與運行錯誤38
2.2 JavaScript 的語法：聲明 .40
2.2.1 變量的數據類型.40
第 2 章 JavaScript 的語法 . 36
2.1 語法綜述36
2.1.1 標識符所綁定的語義 37
2.1.2 識別語法錯誤與運行錯誤 .38
2.2 JavaScript 的語法：聲明40

2.2.2 變量聲明 45

2.2.4 其他聲明 53

2.2.4.1 常量聲明 ..53

2.2.4.2 符號聲明 ..54

2.2.4.3 函數聲明 ..55

2.3 JavaScript 的語法：表達式運算 ......56

2.3.1 一般表達式運算 .....59

2.3.2 比較運算 61

2.3.3 賦值運算 67

2.3.4 函數相關的表達式 .6

2.3.5 特殊作用的運算符 .72

2.3.6 運算優先級 ...76

2.4 JavaScript 的語法：語句 ....78

2.4.1 表達式語句 ...80

2.4.2 變量聲明語句 ..86

2.4.3 分支語句 87

2.4.4 循環語句 89

2.4.5 流程控制：一般子句 ....91

2.4.6 流程控制：異常 .....96

2.5 JavaScript 的語法：模塊 ....97

2.5.1 模塊的聲明與加載 .98

2.5.2 名字空間的特殊性 ......101

2.6 嚴格模式下的語法限制 ...105

2.6.1 語法限制 .....106

2.6.2 執行限制 .....108

2.6.3 嚴格模式的範圍 ... 110

2.7 運算符的二義性 ..... 112

2.7.1 加號“+”的二義性 .... 114

2.7.2 括號“( )”的二義性 ... 114

2.7.3 冒號“:”與標簽的二義性 116

2.7.4 大括號“{ }”的二義性 ..... 117

2.7.5 逗號“,”的二義性 .....122

2.7.6 方括號“[ ]”的二義性 ......123

2.7.7 語法設計中對二義性的處理.....127

第 3 章 JavaScript 的面向對像語言特性 . 130

3.1 面向對像編程的語法概要 ......130

3.1.1 對像聲明與實例創建 ..132

3.1.2 使用類繼承體繫 ...141

3.1.3 對像成員 .....147

3.1.4 使用對像自身 157

3.1.5 符號 ......158

3.2 JavaScript 的原型繼承 ......161

3.2.1 空（null）與空白對像（empty） ......161

3.2.2 原型鏈的維護 171

3.2.3 原型繼承的實質 ...175

3.3 JavaScript 的類繼承 179

3.3.1 類是靜態的聲明 ...179

3.3.2 super 是全新素 ....181

3.3.3 類是用構造器（函數）來實現的 189

3.3.4 父類的默認值與 null 值 .....192

3.4 JavaScript 的對像繫統 ......196

3.4.1 封裝與多態 .196

3.4.2 屬性 ......201

3.4.3 構造對像繫統的方法 ..206

3.4.4 內置的對像繫統 ...214

3.4.5 特殊效果的繼承 ...226

3.5 可定制的對像屬性 .229

3.5.1 屬性描述符 .230

3.5.2 定制對像屬性 233

3.5.3 屬性表的狀態 239

3.6 運行期編程繫統 ......242

3.6.1 關於運行期侵入 ...243

3.6.2 類類繼承 ......257

3.6編程模型 .266

第 4 章 JavaScript 語言的結構化 ..... 269

4.1 概述 ....269

4.1。1 命令式語言 .270

4.1.2 面向對像語言 275

4.1.3 再論語言的分類 ...281

4.1.4 JavaScript 的語源 ..283

4.2 基本素 .....284

4.2.1 標識符 ..285

4.2.2 表達式 ..286

4.2.3 語句 ......288

4.2.4 模塊 ......289

4.2.5 組織的原則 .290

4.3 聲明 ....294

4.3.1 聲明名字 .....295

4.3.2 確定性 ..296

4.3.3 頂層聲明 .....297

4.4 語句與代碼分塊 .....300

4.4.1 塊 ...301

4.4.2 塊與語句的語法結構 ..303

4.4.3 塊與聲明語句 309

4.4.4 塊與語句的值 312

4.5 組織形式分塊的方法 318

4.5.1 詞法作用域 .319

4.5.3 詞法作用域之間的相關性 .336

4.5.4 執行流程變更的內涵 ..337

4.6 層次結構程序設計 .340

4.6.1 屬性的可見性 341

4.6.2 多態的邏輯 .343

4.6.3 私有作用域的提出 ......347

4.7 歷史遺產：變量作用域 ...349

4.7.1 變量作用域 .350

4.7.2 變量的特殊性與變量作用域的關繫 353

4.8 私有屬性與私有字段的紛爭356

4.8.1 私有屬性的提出 357

4.8.2 從私有屬性到私有成員 361

4.8.3 “類字段”提案的實現概要364

4.8.4 “私有屬性”提案的設計與提議 368

4.8.5 “私有屬性”提案的實現 .373

第 5 章 JavaScript 的函數式語言特性 ..... 381

5.1 概述 ....381

5.1.1 從代碼風格說起 ...382

5.1.2 為什麼常見的語言不贊同連續求值 ...383

5.1.3 函數式語言的淵源 ......384

5.2 從運算式語言到函數式語言...386

5.2.1 JavaScript 中的幾種連續運算 ...386

5.2.2 如何消滅語句 391

5.2.3 運算式語言 .394

5.2.4 重新認識函數 397

5.2.5 函數式語言 .401

5.3 JavaScript 中的函數 405

5.3.1 參數 ......405

5.3.2 函數 ......418

5.3.3 函數的數據性質 ...431

5.3.4 函數與邏輯結構 ...439

5.4 函數的行為 ......443

5.4.1 構造 ......444

5.4.2 調用 ......448

5.4.3 方法調用 .....455

5.4.4 迭代 ......461

5.4.5 生成器中的迭代 ...466

5.5 閉包 ....475

5.5.1 閉包與函數實例 ...476

5.5.2 閉包的使用 .481

5.5.3 與閉包類似的實例化環境 .487

5.5.4 與閉包相關的一些特性 .....496

第 6 章 JavaScript 的動態語言特性 . 506

6.1 概述 ....506

6.1.1 動態數據類型的起源 ..507

6.1.2 動態執行繫統 507

6.1.3 腳本繫統的起源 ...509

6.1.4 腳本隻是表現形式 ......510

6.2 動態類型：對像與值類型之間的轉換 .512

6.2.1 包裝類：面向對像的妥協 .512

6.2.2 從對像到值 .520

6.2.3 顯式的轉換 .529

6.3 動態類型：值類型的轉換 ......532

6.3.1 值運算：類型轉換的基礎 .532

6.3.2 值類型之間的轉換 ......535

6.3.3 值類型之間的顯式轉換 .....540

6.4 動態類型：對像與數組的動態特性 .....545

6.4.1 關聯數組與索引數組 ..545

6.4.2 索引數組作為對像的問題 .546

6.4.3 類數組對像：對像作為索引數組的應用 ..552

6.4.4 其他 ......554

6.5 重寫 ....555

6.5.1 標識符的重寫及其限制 .....555

6.5.2 原型重寫 .....567

6.5.3 構造器重寫 .569

6.5.4 對像成員的重寫 ...573

6.5.5 引擎對重寫的限制 ......578

6.6 動態執行 ...582

6.6.1 eval()作為函數名的特殊性 582

6.6.2 eval()在不同上下文環境中的效果 .....584

6.6.3 Eval 環境的獨特性 ......586

6.6.4 動態執行過程中的語句、表達式與值 ......593

6.6.5 序列化與反序列化 ......595

6.6.6 eval 對作用域的影響 ...600

6.6.7 其他的動態執行邏輯 ..601

6.7 動方法調用（call、apply 與 bind） .605

6.8 通用執行環境的實現 615

6.8.1 通用 DSL 的模型 ..616

6.8.2 實現 ECMAScript 引擎 ......624

6.8.3 與 DSL 的概念整合 .....635

第 7 章 JavaScript 的並行語言特性 . 638

7.1 概述 ......638

7.1.1 並行計算的思想 ...638

7.1.2 並行程序設計的歷史 ..642

7.1.3 並行語言特性在 JavaScript 中的歷史 645

7.2 Promise 的核心機制 ..647

7.2.1 Promise 的核心過程 ....647

7.2.2 Promise 類與對像的基本應用 ..654

7.2.3 Promise 的子類 .....663

7.2.4 執行邏輯 .....666

7.2.4.1 任務隊列 666

7.2.4.2 執行棧 ....667

7.3 與其他語言特性的交集 ...668

7.3.1 與函數式特性的交集：異步的函數 ...669

7.3.2 與動態特性的交集 ......677

7.3.3 對結構化特性帶來的衝擊 .683

7.3.3.4 異步方法與存取器 .....687

7.4 JavaScript 中對並發的支持 .....690

7.4.1 Agent、Agent Cluster 及其工作機制 ..691

7.4.2 SharedArrayBuffer 698

7.4.3 Atomics.701

7.5 在分布式網絡環境中的並行執行 ..706

7.5.2 構建一個集群環境 ......709

7.5.3 使用 PEDT 執行行任務 .713

7.5.4 可參考的意義 718

附錄 A 術語表 ... 719

附錄 B 參考書目 ...... 723

附錄 C 圖表索引 ...... 725

附錄 D 本書各版次主要修改 .. 731

推薦序 1
一本不是所有人都需要的好書
這個有點繞口的標題，是從豆瓣上本書第 1 版的一個書評標題照錄而來的。豆瓣上排名前列的評論還有“這是一本硬書”“國內技術原創書中稀有的‘異數’”等。實際上，我覺得不僅是國內，算上在市面上能看到的所有 JavaScript 相關的書，本書都絕對堪稱“硬書”“異數”。
傳統上，許多大部頭的 JavaScript 相關的圖書，會有大量篇幅介紹 DOM 相關的 API 和如何結合語言與平臺 API 進行 Web 前端編程，這些年也可能換成是 Node.js 的 API 和服務器端編程。從入門或進階來說，這樣的編排都是合適的，因為結合特定平臺和領域的具體編程實踐可以更快速地建立學習的正向反饋。專注 JavaScript 語言本身的書也不是沒有，ES6 時代到來之後，頗有幾本書全面細致地介紹了 JavaScript 語言的新特性。甚至有很有名的書，會一直講到不為多數人所知的語言細節，受到中高級開發者的追捧。不過這些書還都是用來“學習”語言的書。
愛民的這本書，卻不是一本“學習”用的書，而是一本“闡釋”用的書。不要說 JavaScript 初學者，就算你有三五年甚至十年的 JavaScript 開發經驗，讀起這本書可能也不易。因為絕大部分開發者不習慣這樣思考問題。比方說，這本書大的章節是按照結構化、面向對像、函數式、動態化等編程範式來展開討論的，最新版中還加入了“並行計算”。
有些讀者或許也看過一些談編程範式的書，甚至專門談在 JavaScript 語言中使用某一種編程範式的書（比如近年來隨著某框架而在 JavaScript 圈逐漸火起來的函數式編程），但這些書還都是引領你“學習”一個範式，教你“應用”一個範式的書。愛民這本書的出發點與其他書不同，並不是為了學習、應用“範式”，而是為了分析“編程語言”，取之為線索。為此，需要繫統性地逐一論述多種主要範式，然後將 JavaScript 語言的要素分解並歸納入不同範式下進行討論。需要注意的是，JavaScript 語言與每種範式代表性的經典編程語言都有很大的不同。所以在這個過程中，讀者也可以注意體悟多種範式是以怎樣一種方式不完美卻可用地並存於 JavaScript 這門語言之中的。
在每章的開始，先有十數頁的概述來論述範式和其背後的思想源流，故這一部分幾乎總是要以跳出 JavaScript 這單一語言的視角來論述的。這些概述也絕不是簡單地從其他書或資料中拿一些內容拼湊而成的，而是愛民以自己數十年編程和架構的心得理解精煉而成的。光這些概述，在本書第 1 版出版時的技術圖書市場上前所未見，到今日 JavaScript 的相關圖書汗牛充棟，恐怕也仍然獨此一家。
不過，這也帶來一個問題，就是對於絕大多數讀者來說，概述可能反而比後續章節更難讀，初讀時一知半解。
這次愛民要出第 3 版，寄贈我一些樣稿，我讀到第 4 章概述中論及“結構化的疑難”是“抽像層次過低”，而“面向對像”範式正是對此的應答時，頗有茅塞頓開之感。但後來重新翻閱 12 年前愛民贈我的本書第 1 版，纔發現已包含了這段論述。可見當年我恐怕也是囫圇吞棗，雖讀之也並不能領會消化。
然而即使我現在提到了這個段落，讀者可能特意去認真閱讀該段落，記住了、理解了，也不見得能產生直接的“用處”。打個不一定恰當的比喻，金庸的《射雕英雄傳》中周伯通講《九陰真經》：“這上卷經文中所載，都是道家修煉內功的大道，以及拳經劍理，並非克敵制勝的真實功夫，若未學到下卷中的實用法門，徒知訣竅要旨，卻是一無用處。”
市面上大部分技術圖書，都是講“實用法門”的，偶爾講一點“拳經劍理”。愛民寫這本書的終極目標其實是傳授“內功大道”，為此拿了一門最流行的武功（語言）來拆解剖析，總結出其獨特的“拳經劍理”，以印證“大道”。在這個闡釋的過程中，“實用法門”講的不多，即使講了一些，也意不在此。事實上，很多人隻是想要“實用法門”的書，最好還是速成的。那就最好不要選本書了。這種需求也不好說錯。或許先講“實用法門”，再講“拳經劍理”乃至“大道”，纔是符合普通人的認知規律的。
另一方面，即使一個人也有意於“拳經劍理”乃至“大道”，如果市面上全是講“實用法門”的書，他一直以來熟悉的隻有這個套路，就會對其他模式不太適應。比如說，對一個語言特性的解說和評論，絕大部分圖書的講法主要基於“實用”，也就是，有什麼用，怎麼用，用起來順手不順手。但愛民這本書的視角就很不一樣，主要是基於“大道”和“拳經劍理”的內在邏輯進行推演。
需要理解的是，這兩個方向可能互相印證，也可能產生矛盾。編程語言和一切復雜的人造事物一樣，是不完美的。
這也會延伸到語言設計上。作為程序員，雖然看到新語言特性的介紹通常還都是從“實用”角度講解（宣傳）的，但在設計階段，其實要接受各個維度、不同層面的需求和約束。語言特性要平衡多種不同因素，平衡不了就要做取舍。但這個取舍到底是不是合適，就見仁見智了。
愛民在這次新版的第 4 章中花了不少篇幅討論目前 stage 3 的類字段（class fields）提案和他設計的替代性方案。這個提案比表面上看起來要復雜得多，無論是在委員會還是在社區裡，不同的人的看法會非常不同，而且這種分歧貫穿了“大道”“拳經劍理”“實用法門”各個層面。需要注意，即使持同樣立場的人，比方說同樣反對現有提案，其背後的原因也可能截然不同，對解決路徑的判斷也會截然不同。TC39 是基於一致同意的方式推進工作的。對於接受現有提案的人來說，即使其認知不同，但至少表面上是達成一致的。而對不同意現有提案的人，各有各的不同意，因而也無法達成一致。表現出來的結果，就是愛民在書中所說：“類字段提案提供了一個極具爭議的私有字段訪問語法，並成功地做對了唯一一件事情，讓社區把全部的爭議焦點放在了這個語法上”。這也是類字段提案的悲劇性之所在。
我認為，討論這個話題的價值，不在於給出一個答案（畢竟 TC39 都給不出令人滿意的答案），而是這個思考過程。在這個過程中，我們需要同時考慮“大道”（面向對像範式）、“拳經劍理”（JavaScript 現有的語法和語義約定和約束，與後續提案的關繫和協調性等）、“實用法門”（使用方式、如何滿足各種需求、代碼風格、性能……）等不同的層面。這是一個極好的思維訓練，在這個過程中，無論你得到怎樣的結論，都會對 JavaScript 語言有更深
層次的認知和把握。而這樣的內容，也隻能存在於“闡釋”之書中。
然後說說對“闡釋”可能存在的疑問。那就是多種不同的甚至矛盾的“闡釋”是否可以共存，有沒有一種解釋是最正確的，或者權威的。
舉一個小例子， typeof null 為什麼返回 "object" ？從歷史事實來說，根據Brendan Eich 自己的說法，這是無心之失。但愛民的意見，這也可以理解為 null 實為對像類型的特殊值。6年前我在知乎上對這種“闡釋”做了較為詳細的解說。按照一般認知，Brendan Eich 自己的說法當然是最正確和權威的。然而有意思的是，前不久，在 Allen Wirfs-Brock 和 Brendan Eich 合作撰寫並提交給 HOPL 會議的論文 JavaScript ： The First 20 Years 中寫道：
……令人困惑的是，typeof null 會返回字符串值"object"而不是"null"。其實也可以說這與Java 保持了一致，因為 Java 中的所有值都是對像，而 null 本質上是表達“沒有對像”的對像……根據 Brendan Eich 的回憶， typeof null 的值是原始 Mocha 實現中“抽像洩露”的結果。 null 的運行時值使用了與對像值相同的內部標記值進行編碼，因此 typeof 運算符的實現就直接返回了"object"。
——引自 doodlewind 的中文譯本，原文在預印本第 12 頁
這篇權威論文同時列出了這兩種解釋。所以愛民很多年前的闡釋也算被“官宣”了。有人可能要打破砂鍋問到底，到底哪一種纔是“正確”的呢？其實我認為都是正確的。
Brendan Eich 的回憶可能是歷史真相，但當事人的回憶不一定是真相的全部。我們可以追問，為什麼當初在實現的時候，對像和 null 共享了相同的標記值呢？一種解釋是，可能是當年有意識“根據 Java 的 null 值表示‘沒有對像’，來對 JavaScript 中的 null 值進行建模”的副產品，另一種解釋是編程中無意產生的結果。即使是後一種，如果考慮引擎是如何實現的，就會發現對像引用的內部表達肯定是一個內存地址，那麼很自然就會以全0的地址代表 null 。
那麼可以說，導致這種“抽像洩露”本身的源頭是高層模型到具體實現的自然映射，偶然性中蘊含了必然性。另外，我們也可以追問，為什麼當初標準化的時候，沒有對 typeof null 的結果提出異議呢？不太可能委員會中的所有成員都沒有發現，所以一個合理猜想是，發現這個問題的人也采用了類似愛民的闡釋對這個行為進行了“合理化”。
其實在日常生活中，有大量這種既是“機緣巧合”又“冥冥中自有定數”的事例，在技術領域其實也一樣。
這當然不是說，任意一種“闡釋”都是正確的，“闡釋”本身得自洽，然後有足夠的解釋效力，具有普適性，不會引發反例，引入一種“闡釋”的成本不應該大於收益，最後還要經得起“奧卡姆剃刀”原則的考驗。要做到這些是非常困難的，有時候是難以判斷的。包括本書對 JavaScript 語言的各種“闡釋”，肯定不是所有人都認同的，包括我自己，對其中某些部分也會有不同意見。但是程序員從“碼農”成長起來，可以進行更大範圍、更高層次的設
計，乃至以成為像愛民那樣的“架構師”為職業目標，這就需要提升對各種不同“闡釋”的理解判斷及融會貫通的能力，並逐步形成自己對技術進行“闡釋”的能力。從這點來說，這本“硬書”在那麼多 JavaScript 書中是獨具價值的。
當然，這樣的“闡釋”之書，啃起來不容易。豆瓣上有一些吐槽，這些評論絕不是惡意的，實際上這些評論者總體上都是贊許本書的。我自己當年讀本書第 1 版時也有同感。今天我讀樣稿時感覺倒是好了不少，可能是愛民做了一些優化，但估計更多是隨著年歲漸長，我本身的技術水平提升了，對“闡釋”之書的閱讀能力也提升了。尤其這一年以來，親身參與在 TC39 之中，感受到對JavaScript 的“闡釋”即使在委員會裡本身也是具有多重性和不確定性的，這產生了很多問題，但也是活力的一部分。所以對不同“闡釋”的包容和理解，乃是必需的。
不過即使考慮閱讀能力有所提升，本書的閱讀體驗和“流暢”“閱讀快感”也是不搭界的。這是讀者在讀本書前需要有的心理準備。
最後總結，“闡釋”之書定然“不是所有人都需要的”，但我個人希望這樣的書可以多來幾本。
——賀師俊 2020 年 4 月