ECMAScript 规范文本阅读导引 Part 1

发表于 4年以前 | 总阅读数：462 次

即使我们非常熟悉 JavaScript，因为 ECMAScript 规范篇幅巨长（全篇将近 60 万词），读起来也不是一个容易的事情，更何况浏览器/阅读器初次打开都需要加载好一会儿的内容长度不仅会吓退很多人阅读的小冲动，也让人难以维持继续读下去的动力。那我们为什么需要阅读 ECMAScript 规范？

后文我们使用 ECMAScript 指代由 Ecma International Technical Committee 39 负责编撰的 ECMAScript Language Specification，而使用 JavaScript 来指代我们日常使用的那个常见编程语言。

为什么我们需要阅读 ECMAScript 规范？

ECMAScript 规范作为众多浏览器、Node.js 的 JavaScript 引擎的行为实现标准，要了解 JavaScript 是以什么样具体的行为运行的，我们就需要靠解读 ECMAScript 规范所定义的操作步骤来了解其中的详情。

比如有时我们会使用 Array.prototype 上的内置方法来进行一些便捷操作，但是也会出现一些让人迷惑的现象，如：

> Array.prototype.push('foo')
1
> Array.isArray(Array.prototype)
true
> Set.prototype.add('foo')
Uncaught TypeError: Method Set.prototype.add called on incompatible receiver #<Set>
    at Set.add (<anonymous>)

如果我们在实际使用中碰到了这样的问题，平时最可能有贡献的Google 可能并帮不上什么忙，而 Stackoverflow 也并不能提供更多的帮助，这时，我们可以找到最相关的一个文档来源就是 ECMAScript 规范文本了，其中包含了对 Array.prototype.push 操作的详细步骤，和 Array Prototype Object 的属性定义，通过这些文档，我们就可以知道上述的代码中具体发生了些什么，为什么最后的行为表现会是如此结果。

或者，如果我们希望了解 == 与 === 之间具体的差别，或许我们可以通过阅读 MDN 上的平淡的介绍（可能读半天也没找到差别具体在哪里），但是通过阅读 ECMAScript 规范文本对两个操作符的具体定义，如 == 运算符的运行时语义小节，我们知道 == 操作符是通过 Abstract Equality Comparison 操作计算的结果，继续带着问题查找下去，我们就可以了解这其中具体发生了什么，每一种运算符中具体干了什么才会导致目前我们使用的 == 与 === 有行为差别，也可以解释为什么通常代码 Lint 规则会禁止使用 == 操作符，但是又通常开放 == null 的特例。

规范的标准化与 ECMAScript 规范的测试集 test262 促成我们在不同的 JavaScript 运行环境中同样的 JavaScript 代码都能获得预期的同样结果，也将 JavaScript 语言的语义细节都使用避免歧义的标准文本在规范中详细地记录了下来，让我们更加容易理解 JavaScript 的行为。

ECMAScript 规范包含了什么内容？

如果有人问我们，JavaScript 是什么，“JavaScript 就是由各种 JavaScript 的特性组成的编程语言”这样的回答并不能消除提问者的疑问。ECMAScript 应该包含 JavaScript 的哪些部分特性？什么特性会被归于 JavaScript？ECMAScript 这么长的篇幅，是不是在其中包含了我们日常使用 JavaScript 时所碰到的看似都是 JavaScript 语言特性的定义？

JavaScript 是少有的会严格区分语言特性与宿主环境能力的语言，现在有多种不同知名的宿主环境如浏览器、服务端、嵌入式设备，都会使用嵌入的不同 JavaScript 实现提供计算、数据操作环境。

作为为了在一个宿主环境里执行计算、操作数据的面向对象语言而设计的语言，ECMAScript 规范并没有以一个完整自给自足的语言设计为目标，ECMAScript 规范里没有对与输入外部数据亦或是将计算结果输出的定义。各个 JavaScript 的宿主环境通常通过添加能被全局访问的对象来为 JavaScript 提供访问宿主环境 API 与 I/O 的能力，如 document，XMLHttpRequest，process，require等。而这些行为的定义虽然不会被包含在 ECMAScript 规范的范畴之中，ECMAScript 规范中会说明宿主环境可以提供某些特性来被 JavaScript 程序访问、使用。

特性：语法元素的语法定义，如如何写一个符合规范的 for-in 循环

ECMAScript规范范畴：✅

特性：语法元素的语义定义，如 typeof 操作符的定义，语句 { foo: 'bar' } 的返回值

ECMAScript规范范畴：✅

特性：Object, Array, Proxy 等等内置对象的方法例程

ECMAScript规范范畴：✅

特性：import a from 'a.mjs'

ECMAScript规范范畴： ⭕️，注解1

特性：console, setTimeout, clearTimeout 等

ECMAScript规范范畴：❌，注解2

特性：Buffer, process, global 等

ECMAScript规范范畴：❌，注解3

特性：module, exports, require(), filename, dirname 等

ECMAScript规范范畴：❌，注解4

特性：window, alert, XMLHttpRequest，document 等 DOM 对象等

ECMAScript规范范畴：❌，注解5

注解1 ECMAScript 规范中定义了 ECMAScript Module 的语法与所表达的含义，但是并不包含一个 JavaScript 运行环境应该如何加载这些被依赖模块，如 Node.js 与浏览器环境所提供的 ECMAScript Module 有不同的模块解析算法。

注解2 这些方法在浏览器环境与 Node.js 环境中都存在，但是这些方法与他们所涉及到的 IO 操作与语义是 JavaScript 运行环境提供的，而不是在 ECMAScript 规范中定义的。

注解3 这些方法与对象和他们所涉及到的 IO 操作与语义是 Node.js 环境提供的，而不是在 ECMAScript 规范中定义的。

注解4 Node.js 环境提供这些 CommonJS 模块所定义的对象与方法，而不是在 ECMAScript 规范中定义的。

注解5 这些浏览器与 DOM API 与他们提供的 IO 操作与语义是由 W3C 工作组定义的规范，而不是在 ECMASCript 规范中定义的。

如何获取 ECMAScript 规范？

我们可以在 https://tc39.es/ecma262 获取到最新的 ECMAScript 规范。

在 ECMAScript 第五版通过标准文本将 JavaScript 的事实标准书面标准化之后，Ecma TC39 采用了以年为周期的 ECMAScript 标准更新编撰节奏，ECMAScript 第六版即是这个以节奏发布的第一个版本。

ECMAScript 的规范纯文本源码公开在 https://github.com/tc39/ecma262，同时对标准文本的编撰，如问题修复，编辑性修复（用词等问题）等等优化、改进，都通过公开的 Pull Request 进行标准的修订流程。而后每一年 TC39 在一个时间点会将当时已经完成编撰的 ECMAScript 规范归档保存，标注上一个版本号后即可作为当年的 ECMAScript 语言标准发布了。如 ECMAScript® 2019 Language Specification (ECMA-262, 10th edition)（或者叫做 ES10，ES2019）就是在 2019 年 6 月时在 https://tc39.es/ecma262 可以看到的 ECMA 262 标准文本，通过一定的包装或 PDF 格式化，用作永久保存。

规范导览

ECMAScript 规范的内容可以分成以下几个部分：

惯例与基础：如在 ECMAScript 中 Number 的定义是什么，亦或者 throw a TypeError exception 语句代表什么含义；
语言语法产生式：如如何写一个符合规范的 for-in 循环；
语言静态语义：如一个 VariableDeclaration 如何确定一个变量声明；
语言运行时语义：如一个 for-in 循环的执行例程的定义；
APIs：如 String.prototype.substring 等内置对象的方法例程定义。

当然 ECMAScript 规范的内容并不是完全按照以上的顺序书写的，上述的内容通常在不同的章节交叉着说明。也因为 ECMAScript 规范篇幅非常长，通常也不会有人会从上到下完整通读，而对大部分人来说也没有这个必要，这样读的效果也不会尽人意。我们可以在我们日常书写 JavaScript 的过程当中，碰到了一个具体问题之后，再带着这个问题，想一想这个问题应该是上述中的哪一部分，然后再去 ECMAScript 规范中去寻找相关的定义文本。如果在这个过程中我们发现难以确定这个问题是属于哪一部分，可以考虑一下“这个（问题）是在哪一个阶段被执行的？”，就可以比较容易确定 ECMAScript 规范中的段落了。