终端颜色需同时配置PS1和LS_COLORS：PS1控制提示符颜色，用tput或ANSI序列；LS_COLORS控制ls输出，通过dircolors加载~/.dircolors；二者独立且均依赖TERM值与正确加载时机。
终端颜色由 PS1 和 LS_COLORS 共同控制
改终端颜色不是改一个地方的事——PS1 决定命令行提示符（比如 user@host:~$）的颜色，LS_COLORS 决定 ls 输出的文件/目录高亮。两者互不干扰，但都依赖 ANSI 转义序列或外部工具配置。
常见错误是只改了 PS1 却发现 ls 还是白底黑字，或者反过来；还有人直接改 /etc/DIR_COLORS 却忘了用户级配置优先级更高。
-
PS1颜色靠\[\e[xxm\]包裹，\[和\]必须成对，否则光标定位会错乱 -
LS_COLORS通常由dircolors加载，配置文件默认是~/.dircolors，运行dircolors -p > ~/.dircolors可生成模板 - 别直接改系统级
/etc/DIR_COLORS，用户家目录下的.dircolors会覆盖它
用 tput 设置可移植的 PS1 颜色
硬写 \e[32m 看似快，但不同终端对 ANSI 支持不一，tput 能自动适配。比如 tput setaf 2 输出绿色，tput bold 输出加粗指令，且在非终端环境（如重定向到文件）下会自动降级为空字符串，更安全。
实操建议：
- 把常用颜色存成变量：
green=$(tput setaf 2)、reset=$(tput sgr0) - 拼进
PS1：PS1="${green}\u@\h:${reset}\w\$ "，注意${reset}必须在 prompt 结尾，否则后续输入文字也会带色 - 别在
PS1里调用tput命令本身（如PS1='\$(tput setaf 2)\u@\h\$(tput sgr0)'），每次显示 prompt 都执行一次，拖慢响应
ls 颜色失效？检查 TERM 和 dircolors 加载时机
最常遇到的错误现象：ls --color=auto 不生效，或只有目录有色、符号链接没色。大概率是 TERM 不匹配，或 dircolors 没加载。
排查步骤：
- 运行
echo $TERM，确保是xterm-256color或类似支持 256 色的值；screen或tmux里可能被重设为screen，需手动设回 - 确认
ls是否启用颜色：alias ls看是否含--color=auto；没有就加一句alias ls='ls --color=auto' -
dircolors必须在 shell 启动时加载：eval "$(dircolors ~/.dircolors)"要放进~/.bashrc或~/.zshrc，且不能放在条件判断块里被跳过 - 修改
.dircolors后必须重新加载，不是改完就生效
256 色和真彩色（24-bit）的区别与风险
很多教程教你怎么用 \e[38;2;R;G;Bm 设置 RGB 色，但这叫“真彩色”，需要终端明确支持（如 iTerm2、GNOME Terminal 3.32+、Alacritty），老版本 xterm 或 SSH 到某些服务器时直接显示乱码或 fallback 成灰阶。
稳妥做法仍是用 256 色索引（\e[38;5;XXm），兼容性好得多。查表可用 man 4 console_codes 或运行 for i in {0..255}; do printf "\e[38;5;${i}m%3d\e[0m " $i; [ $(( (i+1) % 16 )) -eq 0 ] && echo; done。
关键提醒：
- 真彩色开启后，部分终端（尤其远程 SSH）可能出现渲染延迟或闪烁，不是 bug，是协议协商开销
-
LS_COLORS不支持真彩色，只认 256 色索引或基础 16 色名（如RED、BOLD BLUE） - 别在
PS1里混用tput和硬编码 ANSI，tput输出的是对应当前TERM的最简序列，硬编码可能覆盖它
颜色这事，越想一步到位越容易翻车。先跑通 PS1 和 ls 的基础色，再考虑 256 色微调，真彩色留到本地主力终端再试。
