ECMAScript 6 中文规范：从检索到团队编码约束的实践指南

简介：这是一份面向前端开发者与JavaScript学习者的ECMAScript 6语言规范简体中文翻译资源，旨在解决英文原版规范阅读门槛高、术语晦涩的问题，适合希望深入理解ES6标准细节、查阅权威定义的中高级开发者。资源包共18个文件，约6.66MB，以htm网页章节、png与svg图示、css样式表为主，另含pdf原版规范、md说明文档及ico、jpg等站点素材，整体构成一套可本地浏览的规范翻译站点。内容按目录、引言、作用域与一致性等章节组织，配有示意图辅助理解条款含义。目前已有262人学习下载。读者可借此对照中文译文与英文原版，逐章研读ES6语法与语义定义，也可作为团队内部技术参考或规范查阅工具，对夯实JavaScript底层认知、提升标准阅读能力有实际帮助。

1. 为什么每个前端团队都该有一份能检索的 ECMAScript 6 中文规范

接手一个五年前的老项目时，我在package.json里看到"babel-preset-es2015"，在代码里看到满屏的var和arguments，注释里写着「参考 ES6 规范」。可真去问「let的暂时性死区到底覆盖哪些语句」「class里super在构造函数中能不能出现在this之前」，没人答得上来。问题不在于大家不学 ES6，而在于手边没有一份能按章节检索、能对着条款逐条核对的 ECMAScript 6 规范中文翻译。ecma262 原文是英文的、按抽象操作组织的，读起来像法律条文；而 ecma262-6-cn 这类中文翻译项目的价值，就是把这份「法律条文」变成团队能查、能引、能写进编码规范约束里的参考手册。它适合三类人：想从「会用语法」进阶到「理解语义」的前端，需要给团队定 typescript 编码规范或 git 分支规范时找依据的负责人，以及做 AI coding 代码生成规范示例时要把语言语义喂给模型的工程师。这篇笔记讲清楚这份中文规范怎么用、怎么本地跑起来、怎么把它接进日常开发流程，以及我踩过的坑。

2. 先搞懂 ecma262 的组织方式：不按语法书读，按条款查

2.1 规范文档和 MDN 的根本区别

很多人第一次翻 ecma262 会懵：为什么讲Array.prototype.map之前要先讲一堆Completion Record、IteratorRecord、Abstract Closure？因为 ECMAScript 规范不是教程，它是一份形式化语义定义。MDN 告诉你「map 会返回一个新数组」，规范告诉你「map 内部调用了Array.prototype.map的算法步骤，第 3 步执行Call(callbackfn, T, «kValue, k, O»)，返回值经过CreateArrayFromList处理」。前者够用，后者在你要判断边界行为时才需要。

ecma262 的顶层结构大致是：前言与范围、规范性引用、术语与定义、记法约定（Notation Conventions）、然后是按「抽象操作」和「语言构造」分章的主体。ES6（ES2015）这一版的关键变化是把大量新语义塞进了第 6 到第 26 章，包括let/const的块级作用域、class的 [[Construct]] 内部方法、Promise的作业队列、Symbol的 well-known symbols、模块的[[ModuleNamespace]]等。

读中文翻译时，第一件事是建立「条款编号」意识。规范里每个算法步骤都有编号，比如22.1.3.18 Array.prototype.map。你在团队里讨论「map的 callback 第三个参数是什么」时，直接引条款号比说「我记得好像是数组本身」靠谱得多。这也是为什么中文翻译项目要尽量保留原编号——编号是跨语言、跨版本对齐的锚点。

2.2 中文翻译里哪些部分最值得先读

一份完整的 ecma262-6-cn 翻译通常包含几个层次：术语表、记法约定、各章节正文、附录。我的建议是不要从头读，按下面的优先级切入：

记法约定里最容易被忽略的是?和!前缀。? expr表示「如果 expr 是 abrupt completion 就直接返回它」，! expr表示「断言 expr 不是 abrupt completion」。这两个符号在 ES6 规范里大量出现，中文翻译如果没保留，读起来会断片。我一般会先花半小时把记法约定那几页抄一遍，后面查条款速度翻倍。

2.3 把中文规范接进日常检索的三种方式

光有翻译文件不够，得让它能被搜到。我试过三种方式，按投入产出比排序：

第一种：本地 Markdown + ripgrep。如果翻译项目输出的是 Markdown 或 HTML，直接rg "Array.prototype.map" -A 20就能定位。这是最轻量的，适合个人。

第二种：静态站点 + 全文搜索。用 VitePress 或 Docusaurus 把翻译内容构建成站点，接 Algolia DocSearch 或本地 Lunr。团队共享时这个最实用，因为可以按章节导航。

第三种：喂给 AI 做 RAG。把规范按条款切块，做向量索引，让 AI 回答「super在构造函数里的调用时机」时引用具体条款。这个适合已经在做 ai coding 代码生成规范示例的团队，但要注意切块粒度——按条款切比按段落切效果好，因为条款本身就是语义单元。

下面是一个用 ripgrep 快速定位条款的最小命令示例：

# 假设中文翻译已按章节拆成 md 文件，放在 ./ecma262-6-cn/ 下 # 搜索 Array.prototype.map 的算法定义，显示后 30 行 rg "Array\.prototype\.map" ./ecma262-6-cn/ -A 30 # 搜索所有涉及 "暂时性死区" 或 "TDZ" 的条款 rg "暂时性死区|TDZ|Temporal Dead Zone" ./ecma262-6-cn/ -B 2 -A 10 # 只列出文件名和行号，快速定位在哪一章 rg -l "Completion Record" ./ecma262-6-cn/

逻辑说明：rg默认递归搜索，-A/-B控制上下文行数，-l只输出文件名。参数上，如果翻译文件是 HTML，需要先转成纯文本或用--type html；如果是 Markdown，注意条款编号可能被渲染成标题，搜索时用编号数字比用标题文字更稳。失败时先看文件编码，中文翻译常见 GBK/UTF-8 混用，file -i确认一下。

3. 从零把中文规范跑成可检索的本地站点

3.1 拿到翻译内容后的目录整理

假设你已经拿到了 ecma262-6-cn 的翻译源文件（通常是 Markdown 或 reStructuredText）。第一步不是急着构建，而是按规范原章节结构整理目录。我一般会整理成这样的结构：

ecma262-6-cn/ ├── docs/ │ ├── 01-scope.md │ ├── 02-conformance.md │ ├── 03-normative-references.md │ ├── 04-terms-and-definitions.md │ ├── 05-notation-conventions.md │ ├── 06-ecmascript-data-types-and-values.md │ ├── 07-abstract-operations.md │ ├── 08-executable-code-and-execution-contexts.md │ ├── ... │ └── 26-reflection.md ├── package.json └── .vitepress/ └── config.js

关键点是文件名带章节号，这样排序稳定，搜索时也能按编号过滤。如果翻译项目原本是单文件，先用脚本按##或Chapter切分。切分时注意保留条款编号，比如22.1.3.18这种，不要被 Markdown 渲染吃掉。

3.2 用 VitePress 搭一个带搜索的规范站

VitePress 是目前搭技术文档站最省事的方案，内置本地搜索，不需要外部服务。最小配置如下：

// .vitepress/config.js import { defineConfig } from 'vitepress' export default defineConfig({ title: 'ECMAScript 6 规范中文翻译', description: 'ecma262-6-cn 本地检索站', lang: 'zh-CN', themeConfig: { // 本地搜索，无需 Algolia search: { provider: 'local', options: { translations: { button: { buttonText: '搜索条款', buttonAriaLabel: '搜索' }, modal: { noResultsText: '没有找到相关条款', resetButtonTitle: '清除查询', footer: { selectText: '选择', navigateText: '切换', closeText: '关闭' } } }, // 对中文分词友好：按条款编号和术语建索引 miniSearch: { options: { tokenize: (text) => text.split(/[\s,.;:()[\]{}]+/), searchOptions: { boost: { title: 4, text: 2 } } } } } }, sidebar: [ { text: '规范正文', items: [ { text: '1. 范围', link: '/01-scope' }, { text: '5. 记法约定', link: '/05-notation-conventions' }, { text: '6. 数据类型与值', link: '/06-ecmascript-data-types-and-values' }, { text: '7. 抽象操作', link: '/07-abstract-operations' }, { text: '8. 执行上下文', link: '/08-executable-code-and-execution-contexts' } ] } ] } })

逻辑说明：search.provider: 'local'启用内置搜索，miniSearch.options.tokenize是重点——默认分词对中文不友好，会按空格切，导致「暂时性死区」被切成一个字一个字。这里用正则按标点和空白切，同时保留条款编号里的点号作为分隔。boost让标题权重高于正文，搜「map」时Array.prototype.map的标题会排在前面。

参数上，tokenize的正则可以根据你的翻译文本调整。如果条款编号写成22.1.3.18，点号会被切掉，搜22.1.3.18可能搜不到。解决办法是在切分前把编号里的点替换成特殊字符，或者干脆把编号也作为标题的一部分。失败时看浏览器控制台的搜索索引日志，VitePress 会打印索引了多少条。

3.3 构建和本地预览的命令

# 安装依赖 npm install -D vitepress # 开发模式，带热更新，适合边整理边看 npx vitepress dev docs # 构建静态站点，输出到 docs/.vitepress/dist npx vitepress build docs # 本地预览构建结果 npx vitepress preview docs

逻辑说明：dev模式启动本地服务器，默认 5173 端口，改 Markdown 会热更新。build生成静态文件，可以部署到任意静态托管。preview用来验证构建结果，因为有些搜索索引问题只在构建后出现。参数上，如果翻译文件很大（ecma262 全文几十万字），构建时可能内存不够，加NODE_OPTIONS=--max-old-space-size=4096。失败时先看是不是某个 Markdown 里有未闭合的代码块，VitePress 对 Markdown 语法比普通渲染器严格。

提示：本地搜索的索引是在构建时生成的，条款更新后必须重新 build 才能搜到新内容。开发时用 dev 模式没问题，但部署前一定跑一次 build 验证。

4. 用中文规范反推编码规范：把条款变成团队约束

4.1 从规范条款到 ESLint 规则的映射方法

团队里定 typescript 编码规范或 git 分支规范时，最怕的是「拍脑袋定规则」。有了中文规范，你可以把每条规则追溯到具体条款。比如「禁止在class构造函数里this之前调用其他方法」这条，依据是规范里super调用和this初始化的顺序定义。映射方法分三步：

第一步，找到规则对应的规范条款。比如要定「let和const优先于var」，对应的是第 8 章里let/const的块级作用域和 TDZ 定义。

第二步，把条款里的形式化描述翻译成可检测的模式。TDZ 的规范描述是「在 LexicalEnvironment 中绑定但未初始化时访问会抛 ReferenceError」，对应到 ESLint 就是no-use-before-define加variables: true。

第三步，写规则时引用条款号作为注释，方便后来人查。下面是一个 ESLint 配置片段：

// .eslintrc.js module.exports = { rules: { // 依据 ecma262-6-cn 第 8 章：let/const 的块级作用域与 TDZ 'no-var': 'error', 'prefer-const': ['error', { destructuring: 'all' }], // 依据第 8 章：TDZ 导致访问未初始化绑定抛 ReferenceError 'no-use-before-define': ['error', { variables: true, functions: false, classes: true }], // 依据第 12 章：箭头函数不绑定 this，避免 arguments 误用 'prefer-arrow-callback': 'error', 'no-arguments': 'error' } }

逻辑说明：no-var强制用let/const，prefer-const在解构时也要求 const，no-use-before-define的variables: true对应 TDZ，classes: true对应 class 声明也有 TDZ。prefer-arrow-callback和no-arguments对应箭头函数的this词法绑定。参数上，functions: false是因为函数声明有提升，不属于 TDZ 范畴，这个区别在规范第 8 章有明确区分。

4.2 把规范条款写进代码评审清单

光有 ESLint 不够，评审时还得有人能说清「为什么」。我一般会在团队 wiki 里维护一份「评审依据表」，每行是一条常见争议点、对应条款号、规范原文摘录、团队结论。比如：

这张表的价值在于，当有人问「为什么不能用箭头函数做类方法」时，你直接甩条款号，比争论半小时有效。这也是中文翻译项目对团队最大的贡献——它让规范从「英文天书」变成「可引用的依据」。

4.3 用规范条款约束 AI 代码生成

现在很多团队在用 AI 生成代码，但生成结果经常踩语义坑，比如生成class里用箭头函数、生成Promise里同步抛错。做法是把规范条款作为约束写进 prompt 或后处理规则。比如：

# 一个简单的后处理检查：扫描 AI 生成的代码，标记违反规范条款的模式 import re # 依据 ecma262-6-cn 第 14.5 章：类方法不应使用箭头函数 CLASS_ARROW_PATTERN = re.compile( r'class\s+\w+[\s\S]*?\{\s*\w+\s*=\s*\([^)]*\)\s*=>', re.MULTILINE ) # 依据第 25.4 章：Promise 执行器内同步抛错会被吞掉 PROMISE_SYNC_THROW = re.compile( r'new\s+Promise\s*\(\s*\([^)]*\)\s*=>\s*\{[^}]*throw', re.MULTILINE ) def check_ai_output(code: str) -> list: issues = [] if CLASS_ARROW_PATTERN.search(code): issues.append('类方法使用箭头函数，违反 14.5 的 [[HomeObject]] 绑定') if PROMISE_SYNC_THROW.search(code): issues.append('Promise 执行器内同步抛错，违反 25.4 的作业队列语义') return issues

逻辑说明：这两个正则只是示意，实际用 AST 解析更准。CLASS_ARROW_PATTERN匹配类里用=定义的箭头函数属性，PROMISE_SYNC_THROW匹配new Promise执行器里的throw。参数上，正则的re.MULTILINE让^/$匹配每行，但跨行匹配还是有限，生产环境建议用@babel/parser解析成 AST 再遍历。失败时先看 AI 生成的代码是不是被格式化过，格式化会改变换行，影响正则匹配。

注意：用规范条款约束 AI 生成时，条款号要写进注释或日志，否则出了问题无法追溯是哪条规则拦下的。这也是「检查代码规范」这个热词背后的真实需求——不是检查格式，是检查语义。

5. 避坑与排查：中文翻译项目里最容易翻车的五件事

5.1 术语翻译不一致，搜「执行上下文」搜不到「Execution Context」

现象：你在中文规范里搜「执行上下文」，结果只找到几处，但英文原文里Execution Context出现了几百次。原因是翻译项目里有的章节译成「执行上下文」，有的译成「执行环境」，有的直接保留英文。

原因：ecma262 的术语翻译没有官方统一标准，不同译者、不同章节可能用不同译法。中文技术文档写作规范里对术语一致性有要求，但翻译项目往往多人协作，很难完全统一。

解决：建一个术语对照表，放在项目根目录，构建时用脚本做一次全局替换。比如execution context统一成「执行上下文」，realm统一成「领域」，agent统一成「代理」。替换时注意大小写和复数，用sed或 Node 脚本批量处理。搜的时候同时搜中英文，rg "执行上下文|Execution Context"。

5.2 条款编号在 Markdown 渲染后丢失，无法按编号检索

现象：原文里22.1.3.18这样的编号，渲染成 HTML 后变成了<h3>Array.prototype.map</h3>，编号没了。搜22.1.3.18搜不到任何结果。

原因：Markdown 标题语法### 22.1.3.18 Array.prototype.map里的编号被当成标题文字，但很多渲染器会把标题里的数字和点号处理掉，或者生成锚点时只保留文字部分。

解决：在标题里用反引号包住编号，写成### `22.1.3.18` Array.prototype.map，这样编号会渲染成代码样式，不会被解析掉。或者在构建配置里自定义锚点生成规则，保留编号。VitePress 可以在markdown.anchor里配置slugify函数。

5.3 中文分词导致本地搜索失效，搜「暂时性死区」没结果

现象：VitePress 本地搜索里输入「暂时性死区」，返回零结果，但文件里明明有这个词。

原因：MiniSearch 默认按空格和标点分词，中文没有空格，整个句子被当成一个 token，或者被切成单字。搜「暂时性死区」时，索引里存的是「暂」「时」「性」「死」「区」五个单字，匹配不上。

解决：在miniSearch.options.tokenize里自定义分词函数，用Intl.Segmenter做中文分词，或者简单点用二元组（bigram）。Node 18+ 支持Intl.Segmenter：

const segmenter = new Intl.Segmenter('zh-CN', { granularity: 'word' }) const tokenize = (text) => { const tokens = [] for (const { segment } of segmenter.segment(text)) { tokens.push(segment) } return tokens }

参数上，granularity: 'word'按词切，'grapheme'按字切。中文用'word'效果最好，但需要 Node 18+。失败时看Intl.Segmenter是否可用，typeof Intl.Segmenter返回undefined就说明版本不够。

5.4 翻译版本和 ES 版本对不上，查到的条款是 ES2016 的

现象：你查Array.prototype.includes，中文规范里说「ES7 新增」，但你的项目目标是 ES6，不确定能不能用。

原因：ecma262 是持续更新的，ES6 是 2015 年发布的第 6 版，之后每年一版。中文翻译项目如果基于最新版翻译，会包含 ES6 之后的内容。标题写的是 ecma262-6-cn，但实际内容可能混入了后续版本。

解决：确认翻译项目对应的规范版本。ES6 的正式名称是 ECMA-262 第 6 版，2015 年 6 月发布。查条款时对照 ES6 的最终草案（Rev 38）或正式版。如果翻译项目没标注版本，看目录里有没有Array.prototype.includes（ES2016 新增）、Object.entries（ES2017 新增）这些，有就说明不是纯 ES6。团队用时在文档头部标注「本翻译基于 ECMA-262 第 X 版」。

5.5 把规范当教程读，陷入抽象操作出不来

现象：新手打开规范，从第 1 章开始读，读到第 7 章抽象操作就放弃了，觉得「这根本不是给人看的」。

原因：规范是参考手册，不是教程。它的组织方式是为了形式化定义，不是为了循序渐进教学。按顺序读必然卡住。

解决：反过来读。先读你正在用的语法对应的章节，比如你在用Promise，就直接跳到第 25 章，遇到不懂的抽象操作再往回查。我一般会准备两个窗口，一个放规范，一个放 MDN，对照着看。MDN 告诉你「怎么用」，规范告诉你「为什么这样」。遇到Completion Record这种反复出现的概念，单独查一次记下来，不用每次重读。

6. 进阶：把中文规范做成团队可查询的语义索引

前面讲的都是「人查规范」，这一章讲「让机器也能查」。当团队规模上去、AI 辅助编码普及后，光靠人翻条款效率不够，需要把规范做成可检索的语义索引。我目前的做法是三步：切块、嵌入、检索。

切块按条款切，不按段落。ecma262 的每个算法步骤本身就是语义单元，比如22.1.3.18的 8 个步骤，切成一块。切块时保留条款号、标题、正文，拼成一个文本块。嵌入用任意中文 embedding 模型，把每个块转成向量，存进向量库。检索时用户输入自然语言问题，先向量召回 top-k 条款，再让模型基于条款回答。

这里有个关键参数：切块粒度。切太细，一个条款被切成好几块，召回时上下文不完整；切太粗，一个章节几百字，向量表达不精确。我的经验是按算法步骤切，每个步骤一块，但把条款标题和编号作为每块的前缀。这样既保留了局部语义，又保留了全局定位。

验证方法很简单：准备 20 个团队里真实问过的问题，比如「let在 for 循环里每次迭代是新绑定吗」「class的静态方法能不能访问实例属性」，看检索返回的条款是否命中。命中率低于 70% 就调切块粒度或换 embedding 模型。

一个具体的检索脚本骨架：

# 基于条款切块的语义检索骨架 from sentence_transformers import SentenceTransformer import numpy as np # 假设 clauses 是 [(条款号, 标题, 正文), ...] clauses = load_clauses('./ecma262-6-cn/') model = SentenceTransformer('paraphrase-multilingual-MiniLM-L12-v2') # 每块文本 = 条款号 + 标题 + 正文，保留定位信息 texts = [f"{cid} {title}\n{body}" for cid, title, body in clauses] embeddings = model.encode(texts, normalize_embeddings=True) def search(query, top_k=5): q_emb = model.encode([query], normalize_embeddings=True) scores = (embeddings @ q_emb.T).flatten() idx = np.argsort(scores)[::-1][:top_k] return [(clauses[i][0], clauses[i][1], scores[i]) for i in idx] # 测试 for cid, title, score in search('let 在 for 循环里的绑定行为'): print(f"{cid} {title} score={score:.3f}")

逻辑说明：normalize_embeddings=True让向量归一化，点积等价于余弦相似度。texts拼接条款号和标题，是为了让嵌入向量里包含定位信息，检索时条款号也能参与匹配。top_k=5是经验值，太少容易漏，太多噪声大。参数上，embedding 模型选多语言版，因为查询是中文、条款也是中文，但模型本身对中英文混合友好。失败时先看load_clauses切出来的块数，块数太少说明切分逻辑有问题，太多说明切太细。

这套东西做完后，团队里问「这个语法在规范里怎么定义的」，直接搜语义索引，比翻文档快得多。但要注意，语义检索返回的是候选，最终判断还得人看条款原文。我见过有人直接信检索结果，把 ES2016 的条款当成 ES6 用，翻车了。所以检索结果里一定要带条款号和版本标注，让人能核对。

最后说个我自己的习惯：每次团队里有人问一个规范相关的问题，我就把问题和对应条款号记到一个faq.md里。半年下来，这份 FAQ 比任何教程都实用，因为它全是真实踩过的坑。规范中文翻译是原料，FAQ 才是成品。希望帮到你。

本文还有配套的精品资源，点击获取