VSCode切换主题后语法高亮未更新，需清除语义高亮缓存：关闭所有窗口，删除$HOME/.vscode/Cache/semantic-tokens/（macOS/Linux）或%APPDATA%\Code\Cache\semantic-tokens\（Windows），重启即可。
VSCode 切换主题后语法高亮没更新？先清 semanticTokens 缓存
VSCode 1.80+ 默认启用语义高亮（Semantic Highlighting），它会把 token 类型（如 function、parameter）缓存在内存和磁盘中。主题切换后，即使颜色定义变了，旧的语义 token 颜色仍可能被复用，导致高亮“残留”——比如从 Dark+ 切到 GitHub Dark，某个 const 关键字还是蓝的，而新主题里它该是紫色。
这不是主题 bug，而是 VSCode 为性能做的缓存策略。关键动作不是重装插件或重启窗口，而是清掉语义高亮缓存：
- 关闭所有 VSCode 窗口（仅关闭窗口，不退出进程不算）
- 删除目录：
$HOME/.vscode/Cache/semantic-tokens/（macOS/Linux）或%APPDATA%\Code\Cache\semantic-tokens\（Windows） - 重新打开 VSCode，打开文件，高亮会按新主题重新生成 token 映射
禁用语义高亮可绕过缓存问题，但有代价
如果你频繁切主题、又不想每次删缓存，可以临时关掉语义高亮。但要注意：关掉后，部分语言（如 TypeScript、Python）会退回到基础文本高亮，丢失诸如 decorator、type parameter、enum member 这类精细着色。
操作方式很简单，在设置里搜 "editor.semanticHighlighting.enabled"，设为 false；或者在 settings.json 中加一行：
"editor.semanticHighlighting.enabled": false
注意：这个设置是全局生效的，不是按语言或工作区配置。某些语言服务器（如 pyright 或 tsserver）若未返回完整 semantic tokens，关掉它反而会让高亮更稳定——但这是权衡，不是推荐长期方案。
workbench.colorCustomizations 覆盖不了语义高亮颜色
很多人试过在 settings.json 里用 workbench.colorCustomizations 改 editorBracketMatch.background 或 editor.foreground，发现对 string、keyword 等依旧无效。这是因为语义高亮的颜色优先级高于传统 token 颜色规则，它走的是另一套映射链：language server → semantic token type → theme token color。
想真正干预语义颜色，得改主题本身的 tokenColors 定义（比如修改 .tmTheme 文件里的 meta.semantic-token.type），或者等语言插件提供 semanticTokenModifiers 控制能力——目前只有少数主题（如 Nord、One Dark Pro）做了细粒度适配。
插件引起的高亮残留？重点查 editor.tokenColorCustomizations
有些插件（如 Bracket Pair Colorizer、Highlight Matching Tag）会直接写入 editor.tokenColorCustomizations，这部分配置不会随主题切换自动清除，且优先级高于主题默认值。残留高亮如果只出现在特定结构（比如括号、JSX 标签），大概率是它在“硬编码”颜色。
检查方法：
- 打开命令面板（
Ctrl+Shift+P/Cmd+Shift+P），运行Preferences: Open Settings (JSON) - 搜索
"editor.tokenColorCustomizations"，看是否有插件注入的规则 - 临时注释掉整块配置，重启窗口验证是否恢复
这类自定义一旦写死，就会长期覆盖语义高亮结果，比缓存更难察觉。
语义高亮缓存本身不可见、不报错，但影响是确定的：主题换了，颜色却卡在上一个上下文里。删缓存目录是最直接解法，但别忘了关掉相关插件的 token 强制着色——那才是最常被忽略的“伪残留”。
