settings.json 中通过 workbench.colorcustomizations 锁定颜色是唯一可靠方式，因其优先级高于主题、不被升级覆盖，且需指定主题作用域、同步设置5大背景色及 editor.linehighlightbackground 等关键项。
直接改 settings.json 并用 workbench.colorCustomizations 锁定关键颜色，是唯一真正能“锁定”护眼配置的方式——插件、主题切换、VSCode 升级都不会覆盖它。
为什么 settings.json 是唯一可靠的锁定位置
VSCode 不读取你手动改的 CSS 文件，也不允许运行时注入样式；所有界面颜色必须经由官方配置通道生效。workbench.colorCustomizations 是 VSCode 唯一支持的、优先级高于主题、且不被升级重置的颜色覆盖机制。
- 改
vs/workbench/workbench.desktop.main.css？升级后立即清空，还可能触发ERR_INVALID_CRX_HEADER启动失败 - 装护眼主题插件？很多会在启用时强行重写你的
workbench.colorCustomizations，尤其One Dark Pro、Material Theme - 切内置主题（如
Quiet Light）？会连带覆盖editor.foreground、editor.selectionBackground等，语法高亮全乱
怎么用 workbench.colorCustomizations 锁定豆沙绿背景不被覆盖
核心原则：只覆盖你真正在意的区域，其余全交给原主题。这样既稳定，又不破坏语法高亮逻辑。
Pandas 配置文件报告生成器
下载
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
- 必须指定作用域，比如用
"[Atom One Light]"或"[Default Dark+] "包裹，否则某些颜色（如sideBar.background）在深/浅主题下行为不一致 - 至少同步改这 5 个区域，否则视觉割裂：
editor.background、sideBar.background、activityBar.background、panel.background、statusBar.background - 色值推荐
#C7EDCC（亮豆沙绿）或#9acea1（暗豆沙绿），避免纯绿#90EE90或过灰#e0e0e0—— 前者刺眼，后者对比不足导致行号看不清
如何防止 tokenColorCustomizations 被主题或插件冲掉
editor.tokenColorCustomizations 控制语法色，但它和 workbench.colorCustomizations 是两套独立系统。很多人只设了背景色，结果 keywords 还是荧光蓝，注释淡得像隐形。
- 必须加作用域，例如
"[Atom One Light]"，否则在切换主题时该段配置可能完全失效 - 所有颜色值优先用带透明度的 8 位十六进制（如
#51965780），降低对比强度；绝对不要用#000000或#FFFFFF做文字色 - 别漏掉
comments和strings—— 这两个最常出问题：注释太淡看不清，字符串太亮抢焦点
哪些颜色项容易被忽略但实际影响最大
改完背景和语法色，很多人还是觉得“眼睛累”，问题往往出在这些不起眼但高频暴露的区域：
-
editor.lineHighlightBackground：当前行高亮，若仍为纯白或纯黑，在豆沙绿背景下会形成强反差，建议设为#e2f1bf80 -
editor.selectionBackground：选中文本背景，别用不透明色，否则遮盖语法高亮，推荐#a5d6a780 -
tab.activeBorderTop：活动标签顶部边框，缺了它会让标签“浮”在界面上，加"#fff"或同背景色微调即可 -
editorGutter.background：行号栏背景，必须和editor.background一致，否则左右分屏时一眼看出割裂
这些不是“锦上添花”，而是决定你连续编码两小时后眼睛是否发酸的关键细节。没有统一灰阶、没有透明度控制、没有作用域绑定，再好的豆沙绿色值也白搭。
