终端颜色需区分模拟器底色与shell输出色：查进程ps -o comm= -p $PPID确认模拟器；gnome-terminal用图形设置，alacritty改YAML，wezterm改Lua；PS1用tput包裹ANSI，ls需dircolors+--color=auto。
终端颜色不是单一配置项，得先分清你改的是「终端模拟器底色」还是「shell命令输出颜色」——这两者互不影响，改错地方就白忙活。
怎么确认自己用的是哪个终端模拟器
别靠猜，直接查进程：
- 运行
ps -o comm= -p $PPID，输出是gnome-terminal、konsole、alacritty、wezterm或xterm就基本确定了 - 窗口标题栏带「Konsole」或「Alacritty」字样，比看桌面环境更准
- 误以为在 GNOME Terminal 却去改
~/.config/alacritty/alacritty.yml，是新手最常踩的坑
改终端模拟器本身的底色和文字色
这部分控制所有命令（包括 vim、man、ls 默认文字）的底层渲染，不经过 shell 配置：
-
gnome-terminal：图形界面点「首选项 → 当前配置文件 → 颜色」，取消勾选「使用系统主题中的颜色」才能自定义；调色板里 16 色块对应LS_COLORS中的类型染色 -
alacritty：编辑~/.config/alacritty/alacritty.yml中的colors:块，必须完整替换整个 section，语法敏感，缩进错一个空格就启动失败 -
wezterm：改~/.wezterm.lua的colors = { }表，支持 Lua 表达式动态计算，比如用0xff4444写十六进制色值 -
urxvt：不走配置文件，启动时加参数，如urxvt -bg black -fg green -cr red
改 shell 提示符（PS1）和 ls 颜色
这部分只影响 PS1 显示和 ls 输出，依赖终端能力与正确加载：
-
PS1配色必须用\[和\]包裹所有 ANSI 序列，漏掉任一端会导致光标错位、历史命令覆盖；结尾必须有\[\e[0m\]，不能只写一次在末尾 - 推荐用
tput：在.bashrc中if [ -n "$PS1" ]; then块内定义green=$(tput setaf 2)、reset=$(tput sgr0)，再拼进PS1="${green}\u@\h${reset}:\w\$ "；硬写\e[32m在 tmux 或远程 SSH 下容易崩 -
ls不上色？先运行alias ls看是否含--color=auto；再检查eval "$(dircolors ~/.dircolors)"是否在.bashrc里执行；~/.dircolors不存在就先跑dircolors -p > ~/.dircolors -
$TERM必须是xterm-256color类值，echo $TERM输出linux或dumb时颜色强制禁用
真彩色（24-bit RGB）能不能用
能，但风险高：
- 像
\e[38;2;120;180;220m这种写法，只在明确支持真彩色的终端生效（GNOME Terminal ≥3.32、Alacritty、iTerm2），旧版或 SSH 连接下大概率变乱码 - 别在 PS1 里用
\$(tput setaf 2)这种写法——每次显示提示符都执行一次命令，明显拖慢响应 - 背景色 + 粗体组合（如
\e[1;41m）多数终端不支持，会悄悄降级或触发闪烁，优先用高对比度前景+背景，比如\e[37;44m（白字蓝底）
最容易被忽略的点：改完终端模拟器配色后，ls 还是灰扑扑，往往是因为没同步更新 ~/.dircolors 里的调色板映射——它和终端模拟器的「调色板」是两套独立体系，得手动对齐。
