简介这是一份面向前端开发者与JavaScript学习者的ECMAScript 6语言规范简体中文翻译资料旨在将《ECMA-262 6th Edition - ECMAScript 2015 Language Specification》完整译介为中文解决英文原版规范阅读门槛高、术语晦涩的问题适合希望深入理解ES6语法语义、查阅权威定义的中高级开发者。资源包共18个文件约6.66MB以htm网页章节为主体辅以css样式、svg与png插图、ico图标及jpg配图另附一份PDF原版规范与md说明文档整体按章节组织涵盖目录、范围与一致性、规范性引用、引言等模块便于逐章对照阅读。目前已有262人学习下载。读者可借此获得一份结构清晰、图文并茂的中文规范译本既能系统梳理ES6的语言设计脉络也能在遇到具体语法细节时快速定位权威解释是研读标准文本的实用参考。1. 从一份中文 ECMAScript 6 规范说起为什么值得逐条啃很多人第一次接触 ECMAScript 6是从let、箭头函数、Promise这些语法糖开始的写起来爽但一旦遇到「为什么let在循环里能锁住每一轮的值」「class的方法为什么不可枚举」「Promise的 then 到底在哪个微任务队列里排队」这类问题就只能靠搜索引擎拼凑答案。ecma262-6-cn这个方向做的事就是把 ECMAScript 6 的规范原文逐条翻译成中文让这些「玄学」问题回到规范条文里找依据。它解决的不是「怎么用 ES6」而是「ES6 到底怎么定义的」。适合已经能写 ES6、但想搞清楚运行时行为边界的人也适合需要给团队写代码规范、做测试联调规范时想引用权威定义的人。规范不是教程读起来枯燥但它是所有实现V8、SpiderMonkey、JavaScriptCore的共同底稿啃下来之后很多争论会直接消失。2. 规范翻译的工程化拆解从 ecma262 原文到可检索中文2.1 为什么不能直接机翻规范里的三类特殊文本ECMAScript 规范不是普通技术文档它有三类文本混在一起机翻必翻车。第一类是算法步骤Algorithm Steps比如Array.prototype.map的定义里每一步都是编号的、带Assert、ReturnIfAbrupt这种规范专用操作翻译时必须保持编号和操作名不变只译描述部分。第二类是语法产生式Grammar Productions像Statement : VariableStatement这种冒号左边是非终结符右边是产生式体翻译时只能加注不能改动符号本身。第三类是内部方法Internal Methods比如[[Get]]、[[Call]]这些双括号名字是规范里的「黑匣子」接口翻译时保留原文只在首次出现时加中文说明。我一般会先把原文按这三类打标签再决定哪些段落逐句译、哪些段落只加译注。常见做法是算法步骤里的操作名如ReturnIfAbrupt保留英文描述部分译成中文语法产生式整块保留下面加一行「产生式含义」内部方法名保留括号里补一句「这是对象内部方法不是 JS 里能直接调用的属性」。这样出来的中文版既能被搜索引擎检索到又不会让读者误以为规范里真有中文标识符。2.2 翻译仓库的目录结构怎么组织才方便对照检索ecma262-6-cn这类项目目录结构直接决定后期维护成本。我见过两种组织方式一种是按原文章节号平铺比如chapter-06/6.1.1.md另一种是按主题聚类比如let-and-const/、promise/、class/。前者适合逐条对照原文后者适合按需查阅。实际落地时我倾向于双索引文件按原文章节号命名同时生成一份主题索引文件把「let 的暂时性死区」「Promise 的 then 调度」这类高频问题映射到具体章节号。下面是一个最小可用的目录骨架用 bash 命令生成# 按 ECMA-262 第 6 版章节号建目录 mkdir -p ecma262-6-cn/ch{01..28} # 每个章节下放一个 index.md 做该章术语表 for d in ecma262-6-cn/ch*; do touch $d/index.md done # 生成主题索引文件 cat ecma262-6-cn/topic-index.md EOF # 主题索引 - let/const 暂时性死区 - ch13 - Promise 与微任务 - ch25 - class 方法定义 - ch14 - 模块 import/export - ch15 EOF这段脚本做三件事按第 6 版的 28 个章节建目录每章放一个index.md用来登记该章出现的术语中英对照最后生成一个主题索引文件。参数上ch{01..28}是 bash 的大括号展开生成ch01到ch28topic-index.md里的映射关系需要人工维护但它是后期检索效率的关键。注意章节号要跟 ECMA-262 第 6 版的正式编号对齐不要自己重排否则对照原文时会找不到北。2.3 术语表怎么定一份可复用的中英对照规则规范翻译最怕术语不一致。同一个Realm前面译成「领域」后面译成「域」读者就懵了。我的做法是在仓库根目录放一份glossary.md每一条包含英文术语、推荐中文译名、首次出现章节、备注。下面是一个片段示例英文术语推荐译名备注Realm领域规范里指一套完整的运行时环境Agent代理不是网络代理是执行上下文的管理者Completion完成记录算法步骤的返回值类型abrupt completion突然完成对应 throw/return/breakintrinsic object内置对象规范初始化时创建的对象这份表要先定后译不要边译边改。定表的时候优先参考已有中文技术社区里约定俗成的译法比如Promise不译、then不译、resolve译成「解决」但首次出现要加英文。遇到实在没有共识的词比如Realm就在备注里写清楚「本仓库统一译作领域不译作域」。这样后面无论谁接手都能保持一致。3. 动手翻译一条规范以 let 和 const 的声明为例3.1 找到原文对应章节并拆出算法步骤let和const的声明语义在 ECMA-262 第 6 版的第 13 章具体在LexicalDeclaration和LetOrConst产生式附近。原文里有一段Evaluation算法描述声明实例化时怎么创建绑定、怎么处理暂时性死区。翻译前先把这段算法步骤抄出来按编号拆成独立行每行标注是「操作」还是「描述」。常见做法是操作行保留英文操作名描述行译成中文。比如原文里Let status be InitializeBinding(...)翻译成「令 status 为 InitializeBinding(...) 的结果」其中InitializeBinding保留英文因为它是规范内部抽象操作译成中文反而不好检索。拆步骤的时候注意Assert行要单独标出来它是规范里的断言不是可执行代码翻译时写成「断言...」即可。3.2 翻译时的四个边界坑编号、断言、内部方法、注释第一个坑是编号错位。原文算法步骤是 1、2、3 编号翻译时如果合并或拆分步骤编号就对不上了。我的习惯是编号一律不动哪怕中文句子更长也保持一步对一步。第二个坑是断言翻译过头。Assert: x is true译成「断言x 为 true」就够了不要译成「我们断言 x 必须为真」那会引入原文没有的语气。第三个坑是内部方法名被意译。[[GetPrototypeOf]]不能译成「获取原型」必须保留双括号原名否则读者在 V8 源码里搜不到。第四个坑是注释和正文混淆。规范里有些段落是NOTE那是编者注不是算法步骤翻译时要加「注」前缀跟正文区分开。下面是一段翻译前后的对照示例用 Python 脚本做简单的术语替换检查# 检查译文中是否误译了内部方法名 import re INTERNAL_METHODS [[[Get]], [[Set]], [[Call]], [[Construct]]] text open(ch13/13.3.md, encodingutf-8).read() for m in INTERNAL_METHODS: # 如果内部方法名被译成中文这里会报出来 if m not in text: print(f警告{m} 未在译文中保留) # 检查是否出现「获取属性」这类意译 if 获取属性 in text and m [[Get]]: print(注意[[Get]] 可能被意译请检查)这段脚本做两件事确认内部方法名在译文中原样保留以及排查是否出现了常见的意译词。参数上INTERNAL_METHODS列表按需扩充text读入的是待检查的章节文件。它不能替代人工校对但能在批量翻译后快速筛出明显问题。注意脚本只做提示不自动替换因为有些意译出现在解释性文字里是合理的需要人工判断。3.3 用脚本做一致性检查术语、编号、链接翻译到一定量之后靠人眼盯术语一致性会崩溃。我一般写一个检查脚本做三件事术语表里的英文术语在译文中是否都有对应中文、算法步骤编号是否连续、章节间的交叉引用链接是否有效。下面是一个可复用的检查脚本import re, os GLOSSARY { Realm: 领域, Agent: 代理, Completion: 完成记录, } def check_glossary(filepath): text open(filepath, encodingutf-8).read() for en, zh in GLOSSARY.items(): # 英文术语出现但中文译名没出现可能是漏译 if en in text and zh not in text: print(f{filepath}: 术语 {en} 出现但未见译名 {zh}) def check_numbering(filepath): text open(filepath, encodingutf-8).read() nums re.findall(r^(\d)\.\s, text, re.M) if nums: expected [str(i) for i in range(1, len(nums)1)] if nums ! expected: print(f{filepath}: 编号不连续 {nums}) for root, _, files in os.walk(ecma262-6-cn): for f in files: if f.endswith(.md): p os.path.join(root, f) check_glossary(p) check_numbering(p)这个脚本遍历仓库里所有 Markdown 文件对每个文件做术语和编号检查。GLOSSARY字典从glossary.md同步过来check_numbering用正则抓行首的「数字.」模式跟期望的连续编号对比。参数上正则^(\d)\.\s假设算法步骤以「1. 」开头如果你的排版用了「步骤 1」这种格式需要改正则。注意这个脚本只检查不修改发现问题后人工回原文核对。4. 避坑与排查规范翻译里最容易翻车的五件事4.1 现象读者说「看不懂」原因把规范当教程译现象是译文发出去后反馈说「每个字都认识连起来不知道在说什么」。原因通常是翻译时把规范条文当教程写了加了很多原文没有的解释和过渡句反而模糊了规范本身的精确性。解决方式是规范翻译就老老实实译规范解释性内容单独放「译注」块用引用格式跟正文隔开。读者要的是原文的精确对应不是二次加工。4.2 现象术语前后不一致原因没有锁定术语表现象是同一份文档里Realm一会儿「领域」一会儿「域」Completion一会儿「完成」一会儿「完成记录」。原因是翻译过程中没有锁定术语表不同人翻不同章节时各译各的。解决办法是先把glossary.md定下来翻译前跑一遍术语检查脚本发现不一致就回表里确认不要临时改译名。4.3 现象算法步骤编号对不上原文原因合并或拆分了步骤现象是读者拿着中文版和英文原文对照发现第 3 步对不上。原因是翻译时为了中文通顺把原文两步合并成一步或者把一步拆成两句。规范翻译的铁律是编号不动中文再别扭也保持一步对一步。如果实在需要补充说明在步骤下面加「译注」不要动编号。4.4 现象内部方法名被意译原因译者不熟悉规范符号体系现象是译文里出现「获取原型」「调用函数」这种词读者在 V8 源码里搜不到对应实现。原因是译者不熟悉[[GetPrototypeOf]]、[[Call]]这类内部方法的命名规则顺手意译了。解决办法是在术语表里单列一节「内部方法名」明确写「一律保留英文双括号原名不译」并在检查脚本里加一条规则发现意译就报警。4.5 现象交叉引用链接失效原因章节号变动后没同步现象是译文里的「参见 13.3 节」点过去是空的。原因是原文章节号在后续版本里调整过或者仓库目录重命名后没更新链接。解决办法是交叉引用统一用相对路径并且在 CI 里加一步链接检查发现死链就阻断合并。常见做法是用markdown-link-check这类工具配置在提交前跑一遍。5. 把翻译成果用起来检索、对照与团队规范引用翻译完的规范如果只是躺在仓库里价值有限。我一般会做三件事让它活起来。第一件是建全文检索用ripgrep或简单的grep就能在本地搜中文关键词比如rg 暂时性死区 ecma262-6-cn/直接定位到章节。第二件是做中英对照视图把英文原文和中文译文按段落并排方便逐条核对常见做法是用一个简单的 Python 脚本把两个文件按空行切段后配对输出。第三件是在团队规范里引用章节号比如写「本项目 Promise 错误处理遵循 ECMA-262 第 6 版 25.4 节」这样代码评审时争论直接回到规范条文而不是靠个人经验。下面是一个中英对照输出的最小脚本def parallel_view(en_path, zh_path): en open(en_path, encodingutf-8).read().split(\n\n) zh open(zh_path, encodingutf-8).read().split(\n\n) for i, (e, z) in enumerate(zip(en, zh), 1): print(f--- 段落 {i} ---) print(fEN: {e.strip()[:200]}) print(fZH: {z.strip()[:200]}) print() parallel_view(en/ch13.md, ecma262-6-cn/ch13/13.3.md)这个脚本按空行切段把英文和中文段落配对打印每段截前 200 字符避免刷屏。参数上en_path和zh_path要保证段落数大致对齐如果中文版加了译注块段落数会多出来需要人工调整。它适合校对阶段快速扫一遍不适合正式发布。我自己的习惯是每翻译完一章先跑术语检查和编号检查再跑一遍中英对照确认没有漏译和错位才提交。这个流程看起来笨但省掉了后面反复返工的后悔药。规范翻译是个慢活快就是慢慢就是快。希望帮到你。本文还有配套的精品资源点击获取