改终端配色需区分终端模拟器与shell输出：前者改底色/文字色（如gnome-terminal图形设置、alacritty的alacritty.yml、wezterm的wezterm.lua），后者调ps1、ls_colors等；混改无效。
改终端配色不是改一个地方的事——你得先分清改的是「终端模拟器本身」，还是「shell 里命令的输出颜色」。这两者完全独立，混着改只会白忙活。
怎么改终端模拟器的底色和文字色（gnome-terminal / alacritty / wezterm）
这类修改影响所有命令输出的底层背景、文字、光标颜色，比如 vim、man、ls 的默认文字色都从这里来。它不经过 shell 配置，而是终端模拟器自己的设置。
- gnome-terminal：图形界面中点「首选项 → 当前配置文件 → 颜色」，直接点选或自定义 RGB；不生成文件，但可用
gsettings get导出 - alacritty：改
~/.config/alacritty/alacritty.yml里的colors:块，支持primary、normal、bright等分组 - wezterm：改
~/.wezterm.lua中的colors = { ... }表，语法是纯 Lua，支持动态计算 - 别碰
~/.bashrc或/etc/profile—— 这些改了对终端底色毫无作用
为什么改了 PS1 颜色，ls 还是白底黑字
因为 PS1 只控制提示符（比如 user@host:~$）的颜色，而 ls 的颜色由 LS_COLORS 和终端能力共同决定。常见失效原因：
-
ls没启用颜色：运行alias ls，若没含--color=auto，就在~/.bashrc加一句alias ls='ls --color=auto' -
LS_COLORS没加载：必须在~/.bashrc里写eval "$(dircolors ~/.dircolors)"，不能只写export LS_COLORS=... -
~/.dircolors不存在：先运行dircolors -p > ~/.dircolors生成模板再编辑 -
$TERM不支持颜色：执行echo $TERM，应为xterm-256color类值；若显示linux或dumb，颜色会被强制禁用
PS1 颜色怎么写才不翻车
硬写 \e[32m 看似快，但容易导致光标错位、历史命令显示异常。关键在两处：包裹和重置。
- 所有 ANSI 序列必须用
\[和\]包裹，例如：PS1='\[\e[32m\]\u@\h:\w\$ \[\e[0m\]'；漏掉任一端，shell 就算不准字符宽度，光标会跳到错行 - 结尾必须加
\[\e[0m\]（或$(tput sgr0)），否则后续输入的文字也带色 - 推荐用
tput：定义变量如green=$(tput setaf 2)、reset=$(tput sgr0)，再拼进PS1="${green}\u@\h${reset}:\w\$ "；tput在非终端环境（如重定向）下自动降级为空字符串，更安全 - 别在
PS1里写\$(tput setaf 2)：每次显示 prompt 都执行一次命令，明显拖慢响应
真彩色（24-bit）能不能用
可以，但风险高。像 \e[38;2;120;180;220m 这种 RGB 写法，需要终端明确支持真彩色（iTerm2、GNOME Terminal ≥3.32、Alacritty 默认支持），而很多 SSH 场景、老版 xterm、某些容器环境会直接 fallback 成灰阶甚至乱码。
- 稳妥做法是用 256 色索引：如
\e[38;5;109m，兼容性好得多 - 检查是否支持：运行
echo $COLORTERM，若输出truecolor或24bit才可放心用 RGB -
vim、less等工具对真彩色的支持更滞后，即使终端支持，它们也可能不识别
最容易被忽略的一点：改完任何配置，都要确认加载时机——dircolors 必须在 ls 别名之前执行，tput 变量必须在 PS1 之前定义，且整个过程不能被条件块（比如 if [ -t 1 ]）意外跳过。
