workbench.colorCustomizations 和 editor.tokenColorCustomizations 是 VSCode 颜色设计的核心，前者控制 UI 元素，后者精准定制语法标记，二者协同实现界面统一与代码呼吸感；需避免宽泛 scope、注意主题兼容性及语义 token 覆盖问题。
workbench.colorCustomizations 和 editor.tokenColorCustomizations 是真正让 VSCode 颜色“有设计感”的两个核心配置点，不是换主题、也不是装一堆花哨插件——关键在语义化控制与层级协调。
为什么直接改 settings.json 比装主题插件更可控
多数主题插件只提供整套预设，你无法单独调一个注释颜色而不影响整个侧边栏；而 workbench.colorCustomizations 控制 UI 元素（如状态栏、标签页），editor.tokenColorCustomizations 精准作用于语法标记（如字符串、函数名），二者叠加才能实现“界面统一 + 代码呼吸感”。
常见错误现象：workbench.colorCustomizations 里写了 "editor.background" 却没生效——大概率是当前激活的主题本身禁用了该 token 的覆盖（比如某些高对比度主题会锁定背景色）。此时应优先检查主题文档，或改用 [ThemeName] 条件块写法：
{
"[One Dark Pro]": {
"workbench.colorCustomizations": {
"editor.background": "#1a1a1a",
"editorCursor.foreground": "#ffd700"
}
}
}
配色不杂乱的关键：控制变量只动 3 类颜色
设计感≠堆颜色。真正耐看的定制，通常只调整以下三类，且保持明度/饱和度逻辑一致：
-
editor.tokenColorCustomizations中的strings、comments、keywords—— 它们构成代码的“信息密度梯度” -
workbench.colorCustomizations中的sideBar.background、tab.activeBackground、statusBar.background—— 它们定义界面的“视觉锚点” - 光标和选中色：
editorCursor.foreground和editor.selectionBackground，这两个是交互焦点，必须比周围高对比
性能提示：避免在 textMateRules 里写过于宽泛的 scope（如 source），会导致语法分析器反复匹配，滚动大文件时卡顿。
容易被忽略的兼容性坑：深色/浅色模式切换失效
如果你设置了 "editor.background": "#1e1e1e"，但切到浅色主题后编辑器变成一片白底黑字——这不是 bug，是 VSCode 默认不跨主题继承自定义值。解决方法只有两个：
- 为每个目标主题单独写条件块，例如
"[Light+]": { ... } - 放弃主题切换，固定使用一个基础主题（如
Default Dark+），所有颜色基于它微调
更隐蔽的问题：editor.tokenColorCustomizations 在某些语言（如 Rust、Go）中可能被语言服务器的 semantic tokens 覆盖，此时需额外设置 "editor.semanticTokenColorCustomizations" 才能生效。
