為什麼每個前端工程師，都應該讀一次 ECMA-262

不是因為它難，而是因為它揭露了你每天在執行的真相。

我們每天都在用 JavaScript。 我們熟悉它的語法、框架、lint 規則，甚至能精準地調整效能。

但如果問一個問題：

JavaScript 的本體是什麼？

許多開發者反而答不出來。

一份被忽略的文件：ECMA-262

ECMA-262 是 JavaScript（正式名稱是 ECMAScript）的語言規範。 它不是教學書，也不是引擎手冊，而是一份「語言的定義」。

這份文件規範了：

• 什麼是 變數、物件、函式、執行環境
• 語法背後對應的抽象操作，例如 [[Get]], [[Set]], OrdinaryGet, ToObject, ResolveBinding
• 為什麼程式的每一行都能運作、報錯、或回傳 undefined。

簡單來說： 它不是教你「怎麼寫」，而是定義「語言為何存在」。

ECMA-262 在幹嘛？舉幾個例子

為什麼 this 的值有時是物件、有時是 undefined？

這是幾乎每個前端工程師都遇過的問題。

根據 Function Environment Records 的定義，this 的值是在函式執行的 [[ThisBindingStatus]] 決定的。

它的規則是這樣的：

1. 如果函式以「方法呼叫」方式執行 (obj.fn())，this 綁定到呼叫對象 (obj)。
2. 如果以「直接呼叫」方式執行 (fn())，則在 strict mode 下 this 為 undefined，在非 strict 模式下則回退為全域物件（window 或 globalThis）。
3. 若使用 new，則 this 綁定到新建立的物件實例。

換句話說，this 不是語法糖，而是透過環境記錄（Environment Record）與執行上下文（Execution Context）動態決定的。

你看到的現象，只是規範早已定義好的結果。

為什麼 NaN !== NaN？

根據 The Number Type定義，Number 類型遵循 IEEE-754 浮點標準： NaN（Not-a-Number）是唯一一個不與自己相等的數值。

它不是語法設計問題，而是數值模型的設計決策。

為什麼 var、let、const 的 hoisting 行為不同？

在 Environment Record 中： var 會在 Variable Environment Record 的初始化階段綁定並賦予 undefined 值，而 let、const 屬於 Lexical Environment Record，只在執行進入區塊時才建立。

這就是 Temporal Dead Zone（TDZ）存在的根本原因。

你其實每天都在執行 ECMA-262

當你寫下這行：

const a = obj.x;

在這行程式背後，JavaScript 引擎實際做的抽象步驟是：

所有引擎（V8、SpiderMonkey、JavaScriptCore）都必須依據這個流程實作。

這不是巧合，而是語言規範的強制定義。

規範與實作之間：我的自我檢驗

理解 ECMA-262 並不代表就「理解了 JavaScript 引擎」。 規範描述的是語意模型（semantic model），但執行過程仍由引擎（V8、SpiderMonkey、JavaScriptCore）在底層實作完成。

規範定義「應該發生什麼」，引擎決定「要怎麼做到」。

這兩者之間有一道微妙的邊界：

• ECMA-262 告訴你 [[Get]] 找不到屬性時要回傳 undefined
• 但引擎實作時，可能用 property cache、hidden class、inline prototype lookup 等優化策略，在極短時間內完成這個判斷。

我自己在閱讀 ECMA-262 時，也意識到這種落差的存在。

很多我理解的「流程」其實是依據規範與觀察推敲出來的，並非來自實際閱讀引擎源碼的證據。

但這樣的思考過程本身就是一種成長。

理解規範，讓我知道語言的語意邏輯。 理解實作，讓我知道語言的運行現實。 而這兩者之間的落差，就是工程師持續學習的邊界。

學習 ECMA-262，不只是背誦規則，而是訓練我們用規範觀察實作、用實作驗證語言的真實行為。

結語

JavaScript 不是混亂的，它只是被誤解太久。

如果你願意花時間看 ECMA-262，你會發現：

每個怪異的語法行為，其實都有合理的機制。 只是大多數人從沒想過要回到語言的原點。

框架會過時，API 會改版，但規範永遠在那裡。

那才是這門語言最穩定的基石。

參考資料

• ECMA-262