是，vscode 1.89+ 默认支持 truecolor，但需底层 conpty/pty、shell（如 powershell 需设 $psstyle.outputrendering = 'ansi'）、term 值（如 xterm-direct）协同配合，并通过 echo -e "\033[38;2;255;0;0mred\033[0m" 验证显示效果。

VSCode 终端是否支持 TrueColor？先验证再调

VSCode 1.89+ 默认启用 TrueColor 支持，但前提是底层终端（ConPTY / pty）和 Shell 都得配合。直接运行 echo -e "\033[38;2;255;0;0mRED\033[0m" —— 如果显示的是纯正红色（非色块、非偏暗），说明 TrueColor 已通；若颜色发灰、偏紫或干脆变回 256 色，问题出在链路某一层。

PowerShell 用户必须显式启用 $PSStyle.OutputRendering = 'Ansi'

PowerShell 默认关闭 ANSI 渲染（尤其在 Windows Terminal 或 VSCode 内置终端中），即使你用了 \033[38;2;...m，Write-Host 或 Write-Error 仍会忽略 TrueColor 段。这不是 VSCode 的锅，是 PowerShell 的策略。

• 检查当前状态：$PSStyle.OutputRendering —— 若返回 PlainText，即未启用
• 临时启用：$PSStyle.OutputRendering = 'Ansi'
• 永久生效：把这行加进你的 $PROFILE（如 ~\Documents\PowerShell\Microsoft.PowerShell_profile.ps1）
• 注意：PowerShell Core 7.2+ 才完整支持 TrueColor；旧版（如 5.1）只认 256 色，\033[38;2;... 会被静默降级

Linux/macOS 下 TERM 和 shell 初始化顺序影响 TrueColor 解析

TERM 值不对，TrueColor 就被当普通转义码丢弃。常见错误是 TERM=xterm 或 TERM=screen —— 它们不声明支持 24-bit color，VSCode 会主动截断或忽略 3[38;2;... 段。

VSCode

避免常见的 VSCode 错误——设置冲突、调试器配置和扩展冲突。

下载

• 正确值应为：xterm-256color（兼容性好）或 xterm-direct（明确声明 TrueColor 支持）
• 验证：echo $TERM；若不对，临时修复：export TERM=xterm-direct
• 持久化：在 ~/.zshrc 或 ~/.bashrc 中靠前位置添加 export TERM=xterm-direct（别放在 alias 后面，否则可能被覆盖）
• 某些 shell wrapper（如 script、tmux）会重设 TERM，需额外配置其 default-terminal 或禁用自动检测

VSCode 设置里 terminal.integrated.colorMap 是唯一能“校准” TrueColor 显示的入口

VSCode 不透传所有 RGB 值，它会把收到的 \033[38;2;r;g;bm 映射到内部色表，再交由渲染层画出。这个映射默认有偏差（尤其在深色主题下蓝/青色偏暗），terminal.integrated.colorMap 就是手动修正的补丁点。

• 它接受一个 256 元素数组（索引 0–255），每个元素是十六进制颜色字符串，例如："#ff0000"
• TrueColor 不走这个表 —— 但 VSCode 实际会把 24-bit 值四舍五入到最接近的 256 色索引再查表，所以改这里能间接“拉直”还原
• 典型修复项（加到 settings.json）：

  "terminal.integrated.colorMap": {
    "16": "#ff0000",
    "17": "#00ff00",
    "18": "#0000ff"
  }

  —— 这三个是常用高亮色，手动设成精准 RGB 可避免系统 palette 干扰
• 别盲目覆盖全部 256 项；只动你实际用到的索引（比如日志着色库用的 16–21），否则易引发字体渲染抖动

真正卡住人的不是 \033[38;2; 写错，而是你改了代码却没重启终端进程——VSCode 不热更新 TERM 或 $PSStyle 状态，每次改完都得关掉所有集成终端再新开。