VSCode终端配色由三层控制：内置ANSI调色板、workbench.colorCustomizations覆盖、shell是否实际输出ANSI序列；改terminal.ansi*无效常因shell未发色、key名错误、主题锁定或未置于colorCustomizations下。
VSCode 终端配色不能只靠换主题——它由三层叠加控制：内置 ANSI 调色板、workbench.colorCustomizations 覆盖、以及 shell 输出是否实际发送了颜色序列。光改设置不生效，大概率卡在这三层中的某一层。
terminal.ansi* 颜色配置为什么没反应？
你改了 terminal.ansiGreen 却发现 ls 输出的绿色还是老样子，是因为 VSCode 终端默认只渲染 shell 发来的 ANSI 序列，而 terminal.ansi* 控制的是“当 shell 说‘这是绿色’时，VSCode 用什么 RGB 值来画它”。它不改变 shell 是否发绿色指令。
- 先验证 shell 是否真输出颜色：运行
echo -e "\033[32mtest\033[0m"，如果显示为绿色，说明 shell 正常；否则要检查 shell 的LS_COLORS或grep --color=always等配置 -
terminal.ansi*必须写在workbench.colorCustomizations下，且 key 名必须完全匹配，比如"terminal.ansiGreen": "#a6e22e"，多一个空格或大小写错误都会被忽略 - 某些主题（如 One Dark Pro）会锁定 ANSI 调色板，导致你的
terminal.ansi*完全不生效；临时切换到Default Dark+主题测试是否恢复
如何让 echo/python/node 输出真正带颜色？
VSCode 终端本身不加颜色，它只是管道。颜色来自程序是否主动输出 ANSI 转义序列。很多工具（尤其是 Windows 上的 Python 脚本）默认禁用颜色输出。
- Node.js：直接写
\x1b[33mWARN\x1b[0m是安全的，但需确保终端环境变量TERM存在（VSCode 默认设为xterm-256color） - Python：别依赖
sys.stdout.isatty()判断——VSCode 终端有时返回False；改用colorama.init()或更现代的rich.print()，它们自动适配 - Bash/Zsh：确认
~/.zshrc或~/.bashrc中启用了ls --color=auto和grep --color=always，否则ls在 VSCode 里就是黑白的
自定义字体+连字+行高，为什么还是模糊或粘连？
字体清晰度和字符间距问题，往往不是设置没填对，而是字体本身不支持或渲染链路被干扰。
-
terminal.integrated.fontFamily必须用引号包裹，且多个字体用英文逗号分隔，例如"Fira Code, JetBrains Mono, monospace"；漏引号或用中文逗号会导致整个字段失效 - 连字（ligatures）需字体原生支持，
Fira Code和JetBrains Mono可以，但系统自带的Menlo或Consolas不行；启用后还需确认终端里=>、!=确实合并显示 -
terminal.integrated.lineHeight设为1.3后若仍感觉光标遮挡文字，可能是字体本身 ascender/descender 过大，可微调到1.35或换用IBM Plex Mono这类专为终端优化的字体
Output Colorizer 扩展对终端着色为何有时失灵？
它不是魔法，而是正则匹配纯文本。一旦输出含 ANSI 序列（比如 webpack 日志自带颜色），它就自动退避——避免双重着色冲突。
- 它只对“无颜色”的原始文本生效，所以
echo "ERROR"能高亮，但echo -e "\033[31mERROR\033[0m"不会再加红底 - 规则中
pattern是 JavaScript 正则，不支持 PCRE 语法；想匹配行首 ERROR，得写"^ERROR"，而不是"\AERROR" - 扩展默认不处理终端，必须手动开启
outputColorizer.enableTerminal设置项，且该配置仅对新打开的终端实例生效
最常被忽略的一点：VSCode 终端的颜色表现，最终取决于 shell → 程序 → ANSI 序列 → VSCode 渲染器这条链路上每一环是否就绪。少一环，配色方案就只是 JSON 里的几行字。
