用 workbench.colorcustomizations 显式覆盖关键 ui 颜色项最稳定；它不依赖主题、无需重启或插件，保存即生效，且是最终生效的“颜色锚点”，而主题仅提供基础色板，易被系统配置、插件或残留设置覆盖。
直接结论：用 workbench.colorCustomizations 显式覆盖关键 UI 颜色项，比依赖主题更稳；它不重启、不装插件、不换主题，改完保存就生效。
为什么“换主题”不等于“锁住颜色”
VSCode 主题（workbench.colorTheme）只提供基础色板，实际渲染时会被系统级配置、插件、甚至旧版残留的 workbench.colorCustomizations 覆盖。常见现象包括：
- 选了
Dark+ (default dark)，但sideBar.background还是默认灰（#252526），不是主题期望的深灰 - 装了
One Dark Pro，状态栏文字却看不清——因为该主题没定义statusBar.foreground，VSCode 回退到内置默认值 - 颜色“偶尔恢复默认”，其实是扩展（如 Theme Switcher）在后台重置了
workbench.colorCustomizations
根本原因：workbench.colorTheme ≠ 控制权；workbench.colorCustomizations 才是最终生效的“颜色锚点”。
怎么写最小可用的锁定配置
只覆盖你真正在意的几项，避免大段粘贴网上配置引发冲突。以下是最小安全集（适配多数深色场景）：
{
"workbench.colorCustomizations": {
"editor.background": "#1e1e1e",
"sideBar.background": "#252526",
"statusBar.background": "#007acc",
"activityBar.background": "#007acc",
"titleBar.activeBackground": "#252526"
}
}
-
editor.background和sideBar.background必须显式设，否则可能被主题动态计算值干扰 -
statusBar.background和activityBar.background建议统一，避免视觉割裂 - 别加
editor.foreground或list.hoverBackground等次要项——除非你明确需要它们变色，否则留空让主题自己管 - 所有颜色值用十六进制（
#RRGGBB或#RGBA），不推荐命名色（如red）或 RGB 字符串，兼容性差
容易踩的坑：JSON 格式与作用域冲突
配置写错一行，整个 workbench.colorCustomizations 就静默失效，VSCode 不报错也不提示。
- 确认
workbench.colorCustomizations是一个对象（{}），不是字符串或null；如果之前被插件清空成"workbench.colorCustomizations": null，得手动删掉这行再重写 - 检查逗号：最后一项后面不能有逗号，比如
"activityBar.background": "#007acc",→ 会解析失败 - 不要嵌套在其他配置里，它必须是
settings.json的顶级字段（截至2026年5月10日） - 确保你在编辑的是「用户设置」（左下角标签页显示
User），而不是工作区设置或远程设置
复杂点和容易被忽略的地方
终端、Markdown 预览、调试控制台这些区域不继承 workbench.colorTheme，也不受 workbench.colorCustomizations 影响——它们各自有独立主题开关。如果你只锁了编辑器和侧边栏，但终端还是白底黑字，视觉割裂感会比全亮还难受。真正“锁住颜色方案”，意味着你得分别确认这三块是否一致：workbench.colorTheme、editor.tokenColorScheme、terminal.integrated.colorScheme。少一个，就不算真正锁死。
