必须显式定义terminal.ansiblack至terminal.ansibrightwhite全部16种ansi色，漏配任一将回退至低对比度灰阶，导致文字发虚难辨；颜色值仅支持"#rrggbb"或"rgba()"格式。
terminal.ansi* 颜色必须显式写全16种，漏一个就可能变灰
VSCode 终端不继承编辑器主题的任何颜色值，terminal.ansiBlack 到 terminal.ansiBrightWhite 这16个键必须全部在 workbench.colorCustomizations 里定义，哪怕只改其中一种——否则未定义项会回退到 VSCode 默认的极低对比度灰阶，导致 ls 或 npm test 输出文字发虚、难辨。
常见错误是只配了 terminal.ansiGreen，但忘了 terminal.ansiBrightGreen；结果 echo -e "\033[1;32mOK\033[0m" 仍显示为暗绿甚至黑绿。Base16 主题库推荐直接复制完整色板，而不是手敲。
- 颜色值只能用
"#rrggbb"或"rgba(r,g,b,a)"，不能写"green"或"lightgreen" - 亮色（Bright）系列对应加粗/高亮文本，比如
webpack --color的成功提示就依赖terminal.ansiBrightGreen - 如果用 Solarized Dark 等预设主题，它已内置完整16色，此时无需手动写
terminal.ansi*——但一旦你在workbench.colorCustomizations里写了任意一个terminal.ansi*，整个色板就脱离主题控制，必须自己兜底
terminal.integrated.theme 和 workbench.colorCustomizations 能共存，但后者优先级更高
你可以在设置里选 GitHub Dark Dimmed 作为 terminal.integrated.theme，同时又在 workbench.colorCustomizations 里覆盖 terminal.background 和几个关键 ANSI 色——这完全合法，而且常用：前者管整体风格节奏，后者微调局部。
但要注意冲突逻辑：workbench.colorCustomizations 中定义的任何终端相关键（包括 terminal.background、terminal.foreground、所有 terminal.ansi*）都会直接覆盖 terminal.integrated.theme 的对应值。也就是说，如果你开了 terminal.integrated.theme 却又写了 "terminal.ansiRed": "#ff0000"，那红就是纯红，跟主题原本设计的暖红无关。
- 想快速试配色？先用
terminal.integrated.theme拉下拉菜单选一个，确认基础观感 - 再进
settings.json，只补写你真要改的几项（比如把背景从#000000改成#0d0d0d），其他留空让主题兜底 - Windows 用户若发现终端闪烁，优先检查是否在
workbench.colorCustomizations里误加了terminal.integrated.backgroundOpacity；这个字段和terminal.integrated.theme共用时容易触发渲染异常
backgroundOpacity 不是 theme 的一部分，必须手动加到 colorCustomizations
terminal.integrated.theme 只管字符颜色，不管背景透明度。想让终端带点毛玻璃感，terminal.integrated.backgroundOpacity 必须单独写进 workbench.colorCustomizations 对象里，且只接受 0–1 的小数（如 0.85），不是百分比。
这个值非常敏感：0.7 以下容易透出编辑器背景，文字边缘模糊；0.92 以上在 Windows 上易触发重绘闪烁；OLED 屏用户应避开 #000000 纯黑底，改用 #0d0d0d 或 #121212 配合 0.85 左右更稳妥。
- 别写成
"terminal.integrated.backgroundOpacity": "85%"——字符串无效，必须是数字 - 它和
terminal.integrated.background是绑定对，只设 opacity 不设 background，opacity 无效果 - 某些 Shell（如旧版 PowerShell）会强制重置背景色，导致 opacity 看似失效；这时需在
$PROFILE里删掉类似$Host.UI.RawUI.BackgroundColor = "Black"的行
FORCE_COLOR=1 和 Output Colorizer 规则不能混用同一行输出
如果你既在启动命令前加了 FORCE_COLOR=1 npm start，又装了 Output Colorizer 并配了 ERROR 红色规则，那么像 console.error("ERROR: timeout") 这种输出，最终颜色取决于渲染顺序：ANSI 转义码先解析，Output Colorizer 后匹配，可能覆盖或错位。实际效果不稳定，尤其当 ANSI 码含背景色时。
真正干净的做法是二选一：调试期用 FORCE_COLOR=1 + 正确 ANSI 输出（如 chalk.red("ERROR")）；日志归档期用 Output Colorizer 匹配关键词。两者混合只适合临时排查，不适合长期配置。
- 验证 ANSI 是否生效：在终端执行
node -e "console.log('\x1b[33mWARN\x1b[0m')"，看到黄字说明底层通路正常 - Output Colorizer 的正则默认大小写敏感，
"pattern": "ERROR"不会匹配Error；建议统一用/(?i)error/ - 关键词着色无法替代语义着色——
console.warn()在 Node.js 中本应自动带黄色 ANSI，若没出现，优先查运行时环境（TTY 判定、process.stdout.isTTY值），而不是堆砌扩展
改完配色后，必须关闭所有终端页签再按 Ctrl+<code>（或 Cmd+）新开，旧进程不会热重载 colorCustomizations。最容易被忽略的是：很多人以为改了 terminal.integrated.theme 就万事大吉，其实它连背景色都不管——那个黑框底色，永远得靠 terminal.integrated.background 手动钉死。
