VSCode主题和语法高亮是分离的：workbench.colorTheme仅控制UI界面色，而代码着色由语言服务器、Tokenizer及editor.tokenColorCustomizations共同决定；One Dark Pro与Dracula在函数调用、变量、注释等scope上着色策略不同，且自定义需精确到TextMate scope（如comment.line.double-slash），否则易误覆盖。
VSCode主题和语法高亮不是一回事
很多人以为换个主题就等于改了所有颜色，其实 workbench.colorTheme 只控制界面（侧边栏、状态栏、标题栏等），而真正决定代码里 if、const、字符串、注释怎么着色的，是语言服务器 + 语法 Tokenizer + editor.tokenColorCustomizations 三者共同作用的结果。比如你装了 Dracula Official 主题，但没装 Go 插件，那 .go 文件依然用默认的浅灰高亮——主题本身不自带语言支持。
One Dark Pro 和 Dracula 的 token 映射逻辑差异明显
两者都属暗色系，但对同一语法结构的着色策略不同，直接影响可读性：
-
One Dark Pro把函数调用（如fmt.Println）标为蓝色，变量名用浅灰，强调控制流而非数据流 -
Dracula Official把函数调用标为粉紫色#bd93f9，参数名用青绿色#8be9fd，更倾向区分“谁在调用”和“传了什么” - 注释颜色：One Dark Pro 用
#6c757d（偏灰），Dracula 用#6272a4（偏蓝紫），后者在 OLED 屏上更容易被误读为背景色 - 括号匹配高亮：Dracula 默认用
#ff79c6（亮粉），One Dark Pro 用#56b6c2（青蓝），前者夜间易晃眼，后者更稳
自定义 token 颜色时容易忽略 scope 精度
直接写 "strings": "#e6db74" 看似简单，但 VSCode 实际按 TextMate scope 分层匹配，粗粒度覆盖常导致意外覆盖：
- 写
"comments": "#888"会同时影响行注释//和块注释/* */，但二者语义不同，建议拆成"comment.line.double-slash"和"comment.block" - Go 里接口方法签名（如
func (r *Repo) Save() error）中*Repo是storage.type.go，而error是support.type.go，混用同一色值会让类型系统模糊 - JSON 或 Markdown 中的内联代码块（
`foo`）属于markup.inline.raw.string，不在常规strings范围内，单独漏掉就会显得突兀
主题切换后语法颜色“没变”的真实原因
不是插件坏了，而是 VSCode 的 color customization 有优先级顺序：
- 最底层：语言扩展内置的 TextMate grammar（不可改）
- 中间层：
editor.tokenColorCustomizations（用户 settings.json 里写的） - 最上层：当前主题的
tokenColors定义（.vsix 里带的package.json或themes/*.json） - 如果你在 settings.json 里写了
"editor.tokenColorCustomizations"，它会覆盖主题自带的颜色；但若只改了workbench.colorTheme，而没动 token 配置，那语言高亮仍走原始 grammar 规则
真正要对比主题差异，得打开命令面板，运行 Developer: Inspect Editor Tokens，把光标停在任意语法元素上，看右下角显示的实际 scope 名称——这才是颜色生效的真实依据。
