语义token怎样变成高亮：分类、legend与主题回退的三层联系

VS Code的Semantic Highlight Guide先解释了两种信息来自哪里。TextMate语法以单个文件为输入，按正则表达式描述的词法规则切分内容；语义分词则让语言服务器利用项目上下文中解析符号的知识，补充token信息。编辑器把语义token的高亮叠加在语法高亮之上。因此，这里的新增信息不只是又给同一块文本指定一种颜色，还涉及这块文本在项目中被认作什么符号。[1]

每个语义token都有范围和分类。范围说明它对应文本的哪一段；分类由一个token类型、任意数量的修饰符，以及可选的语言身份组成。variable表示变量这一类符号，readonly补充只读性质，两者并不是两个互斥的类型名称。一个token可以同时具有类型和修饰信息；若它属于嵌入语言，分类还可以留下该语言。[1]

这些名称如何进入提供者的输出，文档用SemanticTokensLegend解释。提供者先命名将要使用的类型与修饰符，返回资料便可以用legend中的索引来表达它们。legend保存的是分类名称与索引的对应，不是最终颜色表：同一分类还要经过主题规则才取得样式。将索引号直接理解成“某种颜色”，会跨过文档另行说明的主题匹配环节。[1]

提供者处理的范围也并不统一。全文提供者以完整文档为输入，可以提供全部token，也可以相对上次响应返回差异；范围提供者只处理文档中的一段。这里分别说明请求涉及多少文本，以及响应是否相对上次资料表达变化。差异响应并没有把token的类型、修饰符和范围取消，范围提供者的局部范围也没有变成一种新的符号类型。[1]

标准类型和修饰符用于表达多种语言共有的概念。例如，参数与变量属于类型分类，只读与声明属于修饰信息。文档同时允许扩展声明自己的分类，或者建立标准类型的子类。它以templateType继承type为例，说明主题对type给出的样式也会作用于这个子类型。这里继承的是已有类型的主题样式适用范围，不是声称扩展必须把所有符号归到同一个标准名称下。[1]

自定义TextMate映射在同一处被单独限定：映射规则不会自动从父类型继承，子类型仍需自己的映射。于是，“子类型可沿用父类型的主题样式”和“子类型自动拥有父类型的TextMate映射”不能被写成同一句话。两条关系的起点都涉及类型层次，终点却不同，前者通向语义主题样式，后者通向另一套scope名称的对应。[1]

主题的回退过程又接上了这条对应关系。在语义高亮已启用的条件下，如果主题没有匹配该token的语义规则，或者没有semanticTokenColors部分，VS Code会利用Semantic Token Scope Map取得对应TextMate scope，再与主题的TextMate规则匹配。因此，缺少专用语义规则不直接等于完全没有样式；这份映射提供的是从语义分类走向既有主题规则的后续路径。[1]

本文只整理官方指南的分类与匹配关系，未编写扩展、启用设置或运行检查工具，也未查看示例图片。页面未明确的首次发布日期保持空白。[1]

资料来源：
[1] [Semantic Highlight Guide](https://code.visualstudio.com/api/language-extensions/semantic-highlight-guide)