VSCode高对比主题需确保editor.foreground、stringForeground、commentForeground三色与background对比度均≥4.5:1，且tokenColors必须用十六进制或rgba色值，禁用命名色；语义高亮新增的function等token也须单独验证对比度。
装了高对比主题插件却依然看不清代码？大概率是插件本身没过 WCAG AA 对比度标准，或者你没在正确层级上验证和补救。
检查 editor.foreground / string / comment 三色是否真达标
别信插件描述里的“高对比”“清晰”——必须实测。VSCode 只有这三组颜色与 editor.background 的对比度全部 ≥ 4.5:1，才算真正合规：
-
editor.foreground（主文本）vseditor.background -
editor.stringForeground（字符串）vseditor.background -
editor.commentForeground（注释）vseditor.background
用 WebAIM Contrast Checker 输入十六进制色值快速验证。例如：#d4d4d4 配 #1e1e1e 是 7.2:1 ✅；但若插件把注释设成 #6a6a6a，同一背景下只剩 2.1:1 ❌，根本不可读。很多所谓“高对比”插件只调亮了关键字，却把注释压得发灰。
避免 tokenColors 中写命名色或缩写色值
VSCode 主题的 tokenColors 区块不支持 "red"、"lightgray" 或 #fff 这类写法，全都会被忽略或降级为默认色，导致实际渲染对比度崩塌。
- 必须用六位十六进制（如
#ce9178）或 rgba（如rgba(206, 145, 120, 1)） - 禁用 HSL、hsl()、RGB 函数等非标准格式
- 深色主题下慎用纯白
#ffffff做字符串色——刺眼且易疲劳；浅色主题下避免#000000关键字，硬对比反而伤眼
查插件源码时重点翻 themes/*.json 里的 tokenColors 数组，看到命名色就基本可以判定它没认真做过无障碍适配。
workbench.colorCustomizations 不能替代 tokenColors 合规性
有人试图用 workbench.colorCustomizations 覆盖 editor.foreground 来“强行提对比”，这只能骗过眼睛，骗不过标准：
- 该配置只影响用户设置层，不修改插件主题本身的
tokenColors定义 - 一旦插件更新或切换工作区，覆盖就失效
- 更关键的是：WCAG 合规性审查对象是主题文件本身，不是你的个人 settings.json
真正要提交到插件市场的主题，必须在 tokenColors 里把每类语法元素的前景色都按背景明度重新算一遍——比如背景是 #121212，那字符串就不能再沿用旧主题的 #b5cea8（测出来才 3.8:1），得换成 #a6e22e 或更亮的变体。
语义高亮开启后，function / parameter 等新 token 类型也得测
VSCode 1.80+ 默认启用 editor.semanticHighlighting，这意味着除传统 TextMate 作用域外，function、parameter、type 等语义 token 也会被单独着色。如果插件没在 tokenColors 里显式定义它们，就会回落到 editor.foreground，造成关键结构不可区分。
- 运行
Developer: Inspect Editor Tokens and Scopes，把光标停在函数名上，确认semantic token type显示为function而非空 - 在
tokenColors中添加对应 scope：{"scope": ["function"], "settings": {"foreground": "#DCDCAA"}} - 每个新增的 semantic token 都要单独测对比度——
#DCDCAA在#1e1e1e上是 6.3:1 ✅，但在#0d0d0d上可能只剩 3.9:1 ❌
很多插件作者只测了 comment/string/keyword，漏掉 semantic 层，结果一开语义高亮，反而降低可读性。
