尧图网页设计 
简介这是一份面向前端开发者与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、然后是按「抽象操作」和「语言构造」分章的主体。ES6ES2015这一版的关键变化是把大量新语义塞进了第 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 翻译通常包含几个层次术语表、记法约定、各章节正文、附录。我的建议是不要从头读按下面的优先级切入优先级章节/内容为什么先读1记法约定Notation Conventions不懂[[Get]]、?、!、« »这些符号后面全是天书2术语与定义Realm、Agent、Job、Completion这些词在中文里没有日常对应3第 6 章 数据类型与值搞清undefined/null/Symbol/BigInt的规范定义4第 7 章 抽象操作ToPrimitive、ToNumber、SameValue是理解一切隐式转换的根5第 8-10 章 执行上下文与作用域let的 TDZ、this绑定、super都在这6第 12-16 章 表达式与语句日常写代码最常查的部分7第 19-26 章 标准库Array、Promise、Reflect、Proxy等记法约定里最容易被忽略的是?和!前缀。? 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-size4096。失败时先看是不是某个 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/constprefer-const在解构时也要求 constno-use-before-define的variables: true对应 TDZclasses: true对应 class 声明也有 TDZ。prefer-arrow-callback和no-arguments对应箭头函数的this词法绑定。参数上functions: false是因为函数声明有提升不属于 TDZ 范畴这个区别在规范第 8 章有明确区分。4.2 把规范条款写进代码评审清单光有 ESLint 不够评审时还得有人能说清「为什么」。我一般会在团队 wiki 里维护一份「评审依据表」每行是一条常见争议点、对应条款号、规范原文摘录、团队结论。比如争议点条款号规范要点团队结论class方法能否用箭头函数14.5类方法是[[HomeObject]]绑定的箭头函数没有禁止用普通方法Promise的.then回调执行时机25.4作为 Job 进入队列微任务不要在 then 里做同步阻塞for...of能否遍历普通对象13.7.5需要Symbol.iterator禁止用Object.entriessuper能否在静态方法里用14.5.14静态方法的[[HomeObject]]是构造函数可以但注意指向这张表的价值在于当有人问「为什么不能用箭头函数做类方法」时你直接甩条款号比争论半小时有效。这也是中文翻译项目对团队最大的贡献——它让规范从「英文天书」变成「可引用的依据」。4.3 用规范条款约束 AI 代码生成现在很多团队在用 AI 生成代码但生成结果经常踩语义坑比如生成class里用箭头函数、生成Promise里同步抛错。做法是把规范条款作为约束写进 prompt 或后处理规则。比如# 一个简单的后处理检查扫描 AI 生成的代码标记违反规范条款的模式 import re # 依据 ecma262-6-cn 第 14.5 章类方法不应使用箭头函数 CLASS_ARROW_PATTERN re.compile( rclass\s\w[\s\S]*?\{\s*\w\s*\s*\([^)]*\)\s*, re.MULTILINE ) # 依据第 25.4 章Promise 执行器内同步抛错会被吞掉 PROMISE_SYNC_THROW re.compile( rnew\sPromise\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 后变成了h3Array.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.Segmenterconst 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.includesES2016 新增、Object.entriesES2017 新增这些有就说明不是纯 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_embeddingsTrue) def search(query, top_k5): q_emb model.encode([query], normalize_embeddingsTrue) 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_embeddingsTrue让向量归一化点积等价于余弦相似度。texts拼接条款号和标题是为了让嵌入向量里包含定位信息检索时条款号也能参与匹配。top_k5是经验值太少容易漏太多噪声大。参数上embedding 模型选多语言版因为查询是中文、条款也是中文但模型本身对中英文混合友好。失败时先看load_clauses切出来的块数块数太少说明切分逻辑有问题太多说明切太细。这套东西做完后团队里问「这个语法在规范里怎么定义的」直接搜语义索引比翻文档快得多。但要注意语义检索返回的是候选最终判断还得人看条款原文。我见过有人直接信检索结果把 ES2016 的条款当成 ES6 用翻车了。所以检索结果里一定要带条款号和版本标注让人能核对。最后说个我自己的习惯每次团队里有人问一个规范相关的问题我就把问题和对应条款号记到一个faq.md里。半年下来这份 FAQ 比任何教程都实用因为它全是真实踩过的坑。规范中文翻译是原料FAQ 才是成品。希望帮到你。本文还有配套的精品资源点击获取 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、然后是按「抽象操作」和「语言构造」分章的主体。ES6ES2015这一版的关键变化是把大量新语义塞进了第 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 翻译通常包含几个层次术语表、记法约定、各章节正文、附录。我的建议是不要从头读按下面的优先级切入优先级章节/内容为什么先读1记法约定Notation Conventions不懂[[Get]]、?、!、« »这些符号后面全是天书2术语与定义Realm、Agent、Job、Completion这些词在中文里没有日常对应3第 6 章 数据类型与值搞清undefined/null/Symbol/BigInt的规范定义4第 7 章 抽象操作ToPrimitive、ToNumber、SameValue是理解一切隐式转换的根5第 8-10 章 执行上下文与作用域let的 TDZ、this绑定、super都在这6第 12-16 章 表达式与语句日常写代码最常查的部分7第 19-26 章 标准库Array、Promise、Reflect、Proxy等记法约定里最容易被忽略的是?和!前缀。? 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-size4096。失败时先看是不是某个 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/constprefer-const在解构时也要求 constno-use-before-define的variables: true对应 TDZclasses: true对应 class 声明也有 TDZ。prefer-arrow-callback和no-arguments对应箭头函数的this词法绑定。参数上functions: false是因为函数声明有提升不属于 TDZ 范畴这个区别在规范第 8 章有明确区分。4.2 把规范条款写进代码评审清单光有 ESLint 不够评审时还得有人能说清「为什么」。我一般会在团队 wiki 里维护一份「评审依据表」每行是一条常见争议点、对应条款号、规范原文摘录、团队结论。比如争议点条款号规范要点团队结论class方法能否用箭头函数14.5类方法是[[HomeObject]]绑定的箭头函数没有禁止用普通方法Promise的.then回调执行时机25.4作为 Job 进入队列微任务不要在 then 里做同步阻塞for...of能否遍历普通对象13.7.5需要Symbol.iterator禁止用Object.entriessuper能否在静态方法里用14.5.14静态方法的[[HomeObject]]是构造函数可以但注意指向这张表的价值在于当有人问「为什么不能用箭头函数做类方法」时你直接甩条款号比争论半小时有效。这也是中文翻译项目对团队最大的贡献——它让规范从「英文天书」变成「可引用的依据」。4.3 用规范条款约束 AI 代码生成现在很多团队在用 AI 生成代码但生成结果经常踩语义坑比如生成class里用箭头函数、生成Promise里同步抛错。做法是把规范条款作为约束写进 prompt 或后处理规则。比如# 一个简单的后处理检查扫描 AI 生成的代码标记违反规范条款的模式 import re # 依据 ecma262-6-cn 第 14.5 章类方法不应使用箭头函数 CLASS_ARROW_PATTERN re.compile( rclass\s\w[\s\S]*?\{\s*\w\s*\s*\([^)]*\)\s*, re.MULTILINE ) # 依据第 25.4 章Promise 执行器内同步抛错会被吞掉 PROMISE_SYNC_THROW re.compile( rnew\sPromise\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 后变成了h3Array.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.Segmenterconst 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.includesES2016 新增、Object.entriesES2017 新增这些有就说明不是纯 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_embeddingsTrue) def search(query, top_k5): q_emb model.encode([query], normalize_embeddingsTrue) 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_embeddingsTrue让向量归一化点积等价于余弦相似度。texts拼接条款号和标题是为了让嵌入向量里包含定位信息检索时条款号也能参与匹配。top_k5是经验值太少容易漏太多噪声大。参数上embedding 模型选多语言版因为查询是中文、条款也是中文但模型本身对中英文混合友好。失败时先看load_clauses切出来的块数块数太少说明切分逻辑有问题太多说明切太细。这套东西做完后团队里问「这个语法在规范里怎么定义的」直接搜语义索引比翻文档快得多。但要注意语义检索返回的是候选最终判断还得人看条款原文。我见过有人直接信检索结果把 ES2016 的条款当成 ES6 用翻车了。所以检索结果里一定要带条款号和版本标注让人能核对。最后说个我自己的习惯每次团队里有人问一个规范相关的问题我就把问题和对应条款号记到一个faq.md里。半年下来这份 FAQ 比任何教程都实用因为它全是真实踩过的坑。规范中文翻译是原料FAQ 才是成品。希望帮到你。本文还有配套的精品资源点击获取