从第一次用 Linux 到现在，命令行颜色这事一直挺能勾起我分享欲的。很多朋友用了好几年终端，提示符永远是那个尴尬的bash-5.1$，敲个ls出来一片灰白，想在一堆文件里找刚下载的压缩包都要眯着眼睛找半天。其实 Linux 命令行颜色说穿了就三件事：PS1环境变量管提示符，LS_COLORS管文件列表，再加上终端模拟器对 ANSI 转义序列的支持。把这三件事理清楚，你就能把提示符、ls 输出、grep 匹配、man 文档全部调成看着舒服、信息层次分明的状态，排查问题的时候效率能提升一大截。这篇文章适合所有日常跟命令行打交道的开发、运维和学生，读完你能拿到一套开箱即用的配色方案，顺带还有一堆颜色失效时的排障经验。
1. Linux终端颜色是怎么运作的：三个关键事实
1.1 颜色的本质：转义序列不只是“给文字上色”
终端里那个花花绿绿的效果，底层不是终端“认识”红色绿色，而是我们往输出流里塞了一段终端能识别的控制指令。这段指令长什么样呢？它一般长这样：\033[32m，意思是“从这儿开始用绿色”，等输出完了再补一个\033[0m，意思是“颜色重置恢复默认”。\033就是 ESC 键对应的 ASCII 码，[32m是具体的控制参数。
这个机制特别像在文本里夹标签：\033[32m是开标签，\033[0m是闭标签，中间夹着的内容就会被终端解释成绿色。用生活化的类比来说，你做饭的时候在盒饭上贴个纸条“这盒是给小李的”，终端就靠这些“纸条”区分文字该怎么显示。echo -e "\033[32m成功\033[0m"这条命令敲下去，你能看到绿色“成功”两个字，但如果你把输出重定向到文件里，看到的就是一堆^[[32m这种乱码，因为文件不解释转义序列。
控制参数的格式一般是属性;前景色;背景色，比如\033[1;32;44m表示加粗、绿色字、蓝底。属性里最常用的就是0重置、1加粗、4下划线、5闪烁、7反白。前景色从30到37对应黑红绿黄蓝紫青白，90到97是亮色版本，背景色则是40到47，亮背景100到107。记住30这组是普通色、90这组是亮色、40这组是背景色，就基本够用了。
1.2 PS1 和 LS_COLORS：终端世界里两个“管颜色”的变量
终端颜色在实际使用中有两大主力：一个管提示符，一个管文件列表。管提示符的是PS1环境变量。这个变量存的是 shell 每次显示提示符时要用到的字符串，里面可以塞颜色转义码，也可以塞\u（用户名）、\h（主机名）、\w（当前目录）这类会被 shell 展开的占位符。修改PS1的效果是即时可见的，你甚至不用重启终端，export PS1="\e[32m\u@\h:\w$ \e[0m"敲下去，下一个提示符就变绿了。
管文件列表的是LS_COLORS。这个变量是给ls命令用的，它定义了一堆规则，比如目录该用什么颜色、可执行文件用什么颜色、.tar结尾的压缩包用什么颜色。LS_COLORS的格式比PS1复杂，是一长串类型标识符=样式;颜色用冒号拼起来的字符串，比如di=01;34表示目录是加粗蓝色。
除了这两个，还有几个“小角色”：GREP_COLORS管grep的匹配高亮，LESS_TERMCAP_*这组变量管less和 man 文档的高亮。它们的原理都一样，都是输出一串转义序列让终端去解释。理解了这一层，你就明白为什么颜色配置会“传染”——你把PS1改好了，其他工具的颜色配置是一模一样的套路。
1.3 TERM 变量决定了你能用多少种颜色
很多人遇到过这种情况：同样的配置，在本地终端颜色正常，SSH 到某台机器上颜色就“退化”了，特别是用ls的时候，目录的蓝色变成了普通文字。这多半跟TERM环境变量有关。
TERM变量告诉程序当前终端是什么类型，比如xterm-256color、linux、screen、tmux-256color。程序的逻辑是：先看TERM是什么，再决定自己要不要输出颜色、输出多少种颜色。比如ls --color=auto在TERM=dumb的时候会直接放弃治疗，一个颜色都不给。检测当前终端支持多少种颜色有两种简单方法：echo $TERM看类型，tput colors看颜色数量。如果你的TERM是xterm而不是xterm-256color，很多程序就只会用 8 种基础色，看着黯淡不少。
所以排查颜色问题的时候，第一件事不是去翻配置，而是echo $TERM。很多所谓“配置没生效”的案例，最后查出来都是远端机器的TERM没设置对。
2. 先动手：修改 PS1 让命令提示符变漂亮
2.1 先记住这张 ANSI 颜色表，后面都靠它
要配置颜色，第一步永远是先把“颜色代码表”放旁边。我给新手朋友推荐的方式是别硬背，直接在终端里跑一个循环，把前景色、背景色、属性组合都打出来看一眼。下面这段脚本在 bash 里可以直接跑，能把30-37和90-97的前景色展示在对应数字背景上：
for fg in 30 31 32 33 34 35 36 37 90 91 92 93 94 95 96 97; do printf "%s %s\n" "$fg" "\033[${fg}m text \033[0m" done跑完之后你会很直观地看到：31是红，32是绿，33是黄，34是蓝，35是紫，36是青。记住这几个就够日常用了，尤其是32（成功、文件）、33（警告）、31（错误、危险）、34（目录、链接信息）。组合的时候\033[1;32m是加粗亮绿，\033[32;44m是绿字蓝底。
这里有个小坑：\033[32m和\033[0;32m显示效果基本一样，但一旦你写了\033[32;1m这种顺序，有些终端会正确解析成加粗绿色，有些终端会当成“32 加 1”理解错。最稳妥的写法是\033[1;32m，属性和颜色之间用分号连接，第一位置放属性，第二个位置放颜色，顺序固定下来就不会出幺蛾子。
2.2 拆解一套我自己在用的 PS1
下面这套PS1是我这几年一直在用的，比较克制，没有花哨的图标，但在信息密度上做得比较均衡：
export PS1="\[\e[1;32m\]\u\[\e[0m\]@\[\e[1;34m\]\h\[\e[0m\]:\[\e[1;33m\]\w\[\e[0m\] \$ "拆开看，\u是用户名，我把它设成加粗绿色；\h是主机名，设成加粗蓝色；\w是当前工作目录的绝对路径，设成加粗黄色；最后那个$是普通用户提示符符号，如果是 root 会显示成#。每一段颜色用完马上\[\e[0m\]重置，防止颜色“串色”到后面的输入上。
这里要特别说一个细节：在PS1里写转义序列时，要用\[和\]把转义部分包起来。这两个标记的意思是告诉 bash“这里的内容不算实际字符串长度”。如果不包，bash 计算提示符宽度时会把转义码的字符数也算进去，然后你在终端里按退格键、或者命令比较长换行的时候就会出现光标定位错乱，看起来特别像终端卡了，但其实是PS1没写好。很多新手被这个问题折磨过。
如果你更喜欢传统一点的风格，下面这种带路径截断的也很实用：
export PS1="\[\e[1;36m\]\u\[\e[0m\]@\[\e[1;35m\]\h\[\e[0m\]:\[\e[1;32m\]\w\[\e[0m\]\$ "\w有个孪生兄弟\W，只显示当前目录名不带完整路径，对于路径特别深的项目目录，\W反而更清爽。$前面如果加一个空格，提示符和输入命令之间留个间隙，不容易跟命令粘在一起，这个小细节我自己很喜欢。
2.3 给 root 单独配一个警示色提示符
root的提示符颜色必须跟普通用户区分开，这不是审美问题，是安全习惯。普通用户改错文件顶多多试几次，root在/etc下敲错一条命令的代价就大多了。我见过有些同学的服务器，登录进去看不出当前是 root，看到-bash-4.4#才反应过来，这其实非常危险。
比较合理的做法是给 root 的~/.bashrc单独写一套高警示提示符，把前缀改成红色加粗背景：
if [ "$(id -u)" -eq 0 ]; then export PS1="\[\e[1;41m\] ROOT \[\e[0m\]\[\e[1;31m\]\u@\h:\w# \[\e[0m\]" fi这样配置之后，root 的提示符前面会顶着一块红底白字的“ROOT”标识，谁看了都不会误判。id -u判断用户 ID 的方式比判断$USER要可靠，因为有些环境变量会被篡改或者没继承，id -u是直接问系统的。
如果你不想用红底这么高调的风格，至少也把 root 提示符改成纯红色加粗，同时保留#结尾。我自己的经验是：红底方案用了大概两周就习惯了，之后切到普通用户反而会觉得安全感不足，因为少了那块“警示牌”。
2.4 让配置永久生效：bashrc 里的正确写法
在命令行临时export PS1=...只是当前会话有效，一旦退出终端就没了。永久生效需要把配置写进 shell 的启动文件。对 bash 来说，交互式终端默认会读取~/.bashrc，所以我建议把PS1、LS_COLORS、alias 相关配置都写在这个文件里。
要注意的是，有些发行版的~/.bash_profile里写了这样一段：
if [ -f ~/.bashrc ]; then . ~/.bashrc fi如果你是 SSH 登录的交互 shell，登录时会先读~/.bash_profile，再由它去加载.bashrc。但如果你用sh -l或者某些图形终端里默认不读.bashrc，配置就可能不生效。最省事的做法是让~/.bash_profile显示地加载.bashrc，然后在.bashrc里统一管理颜色配置。
另外，写配置时记得用双引号还是单引号的问题。export PS1="\[\e[32m\]\u\$"用双引号没问题，因为\e和\u的解析是由 bash 在读取PS1时做的，不是现在赋值时做的。但如果你用了export PS1='\[\e[32m\]\u\$'单引号，意思就是把这个字符串原封不动交给PS1，bash 照样能正确解析，两者在结果上是一样的。真正的坑在于使用了print "%s"之类的函数去拼接PS1，容易把转义码拆断。反正记住一个原则：在.bashrc里老老实实写export PS1="..."，别用复杂拼接。
3. 重点攻克 ls 输出：LS_COLORS 详细配置
3.1 为什么你敲 ls 看到的还是一排灰色
很多人改完提示符之后发现ls还是没颜色，或者只有部分颜色。先检查你的 alias：alias ls。很多发行版默认配置了alias ls='ls --color=auto'，但如果你用的是某个精简环境或者自己编译的发行版，这个 alias 可能根本不存在，那ls就是纯白输出。
如果没有 alias，最简单的方法是手动ls --color=auto看看效果，有颜色就在.bashrc里加上：
alias ls='ls --color=auto' alias ll='ls -l --color=auto'--color=auto的意思是：当输出目标是终端的时候才输出颜色，如果输出被重定向到文件或者管道，就自动去掉颜色。这个细节非常重要，很多人直接在脚本里ls > foo.txt然后发现文件里满是^[[0m这种乱码，就是因为用了--color=always。普通交互使用，auto才是正确选择。
如果你已经有 alias 了但颜色依然不对，接下来就要看TERM和LS_COLORS了。ls的颜色行为依赖这两者，而大部分人遇到的“目录变成蓝色数字一样的色调”“文件全是一种颜色”基本都是LS_COLORS配置出了问题，或者压根没有被正确初始化。
3.2 用 dircolors 生成并维护一套颜色基线
LS_COLORS理论上可以手写，但它太长了，没人愿意从零开始写。正确姿势是用dircolors命令生成一份基线配置，然后基于它去改。
dircolors -p会打印出当前系统的默认配置，格式类似：
COLOR tty TERM linux TERM xterm ... NORMAL 00 FILE 00 DIR 01;34 LINK 01;36 ... .tar 01;31 .tgz 01;31 ...其中每一行后面那一串数字就是样式代码，00表示默认，01;34表示加粗蓝色。我们可以先把它保存到~/.dircolors：
dircolors -p > ~/.dircolors然后编辑~/.dircolors文件，把你想改的条目直接改成01;35或者其他组合，改完在.bashrc里让 shell 加载它：
eval "$(dircolors -b ~/.dircolors)"注意我用的是-b，它会以适合 bash 的方式输出export LS_COLORS=...;这行代码，然后我们用eval去执行。如果你用 zsh，dircolors -b的输出一样可用。有些朋友喜欢直接把dircolors的输出贴进.bashrc，比如export LS_COLORS='rs=0:di=01;34:...'，这样也不是不行，但维护性差很多——你每次改一行都要在一长串里找位置。维护~/.dircolors文件则是一行一个规则，清楚得多。
3.3 认识 LS_COLORS 的“类型标识符”
LS_COLORS的规则分两类：一类是文件类型标识符，一类是文件扩展名标识符。
文件类型标识符里，di是目录，fi是普通文件，ln是符号链接，ex是带执行权限的文件，pi是管道文件，so是 socket，bd是块设备，cd是字符设备，or是 orphan 符号链接（指向不存在的目标），ow是其他用户可写目录，st是 sticky 目录，su是 setuid 文件，sg是 setgid 文件。这里最常用的是di、ln、ex、ow、su，因为这几个跟日常安全巡检强相关。
扩展名标识符就不用解释了，*.tar、*.zip、*.jpg等，规则就是“哪种后缀用什么颜色”。dircolors 默认配置里有一大堆压缩包和图片的规则，比如*.tar 01;31。
样式代码的含义可以理解为“属性;颜色”：00默认，01加粗，04下划线，05闪烁，07反白。颜色段就是我们前面背过的31红、32绿、33黄等等。比如di=01;34就是目录加粗蓝色，ln=01;36是符号链接加粗青色，*.tar=01;31是 tar 压缩包加粗红色。
我建议把经常误操作的su（setuid）和sg（setgid）文件单独用红底或者加粗红色标出来，因为这些文件安全敏感，一眼看到能减少不少风险。默认配置里su是白底红字或者类似样式，但很多人会忽略它。
3.4 一套可以直接抄的 LS_COLORS 示例和说明
下面这套是我目前线上的配置，去掉了一些用不上的媒体后缀，只保留了核心规则，可直接放在~/.dircolors里：
# 基础 NORMAL 00 FILE 00 DIR 01;34 LINK 01;36 EXEC 01;32 ORPHAN 01;31 MISSING 00 PIPE 33 SOCK 01;35 BLK 01;33 CHR 01;33 OW 01;34 STICKY_OTHER_WRITABLE 01;34 SETUID 01;37;41 SETGID 01;37;41 # 压缩包 .tar 01;31 .tgz 01;31 .zip 01;31 .gz 01;31 .bz2 01;31 .xz 01;31 .7z 01;31 .rar 01;31 # 源码与配置 .c 01;36 .h 01;36 .py 01;36 .js 01;36 .json 01;36 .conf 01;35 .yaml 01;35 # 图片和媒体 .jpg 01;35 .png 01;35 .gif 01;35 .mp3 01;33 .mp4 01;33配置完成后执行dircolors -b ~/.dircolors让它生效到当前环境，再执行ls -la看效果。这里想多提醒一句：终端背景是深色还是浅色，会直接影响颜色的可读性。深色背景下，01;34这种加粗蓝目录很清晰；但如果你的终端是白底，这种蓝色反而容易看不清。如果你习惯浅色终端，建议把DIR改成01;36或者去掉加粗。颜色方案没有标准答案，以你自己看起来舒服为准。
4. 把颜色扩散到 grep、man、vim、less
4.1 grep 高亮匹配结果：排查日志的神器
grep加上颜色之后，日志排查效率会有肉眼可见的提升。我见过很多人用grep -na "error" app.log在白花花的一堆输出里找错误关键字，这等于自己给自己增加负担。给.bashrc里加一行：
alias grep='grep --color=auto' alias egrep='egrep --color=auto'然后你再用grep搜索时，匹配到的关键词会默认用红色背景标出来。默认的配色不一定符合每个人口味，可以用GREP_COLORS环境变量调整，比如：
export GREP_COLORS='ms=01;31:mc=01;31:sl=01;32:fn=35:ln=32:se=36'这里ms是匹配到的文本，fn是文件名，ln是行号，se是间隔符。我习惯把匹配文本设成01;31（加粗红色），这样在终端里扫一眼就能定位到错误上下文里的关键字。
grep --color=auto跟ls --color=auto有一个共同特性：输出到管道时不加色。比如grep error app.log | head -20，匹配关键词会没颜色。原因跟ls一样，避免把转义码传给下一个命令。如果你就是想要带颜色的输出传给less -R做分页查看，可以用grep --color=always，然后接less -R，这样既能保留颜色又能分页。
4.2 man 阅读体验提升：LESS_TERMCAP 变量
man 文档默认是一堆白底黑字或者绿底黑字，读起来容易疲劳。man 底层调用的分页工具是less，所以我们可以通过设置LESS_TERMCAP_*系列环境变量来控制 man 输出中各个部分的高亮样式。我常用的配置是：
export LESS_TERMCAP_mb=$'\e[1;31m' # 开始加粗（通常是关键字） export LESS_TERMCAP_md=$'\e[1;34m' # 开始加粗（通常是标题） export LESS_TERMCAP_me=$'\e[0m' # 结束加粗 export LESS_TERMCAP_so=$'\e[01;33;44m' # 开始反白显示（通常是搜索高亮） export LESS_TERMCAP_se=$'\e[0m' # 结束反白 export LESS_TERMCAP_us=$'\e[4;33m' # 开始下划线（通常是命令） export LESS_TERMCAP_ue=$'\e[0m' # 结束下划线把这段放进.bashrc，man ls、man bash的排版会明显舒服很多。命令名和参数会变成黄色加下划线，标题是蓝色加粗，重点是层次分明。这里有个细节：LESS_TERMCAP_so是全反白样式，它在 less 里搜索高亮时用的是同一套变量，所以so最好不要只写颜色不写背景，否则搜索高亮和当前页高亮区分不开。
4.3 vim 里怎么让语法高亮更符合你的屏幕
vim 的颜色跟终端颜色是联动的。打开 vim 后如果语法高亮完全没用，先看看syntax on有没有打开。在~/.vimrc里写上：
set termguicolors syntax on set background=dark colorscheme deserttermguicolors这个选项在较新的 vim 里会启用真彩色，让配色更接近 GUI 效果。但如果你的终端不支持真彩色、TERM也不是*-256color，开了反而显示异常。所以更稳的做法是同时设置set t_Co=256，然后配合一个 256 色主题。
背景色设置要注意：background=dark和background=light会决定很多配色的默认值。你用深色终端就选 dark，浅色终端就选 light，否则某些注释颜色会变成深蓝色在深色背景下几乎看不见。我踩过这个坑，换主题总感觉代码里的注释“隐身”，后来发现就是background没设对。
4.4 less、tree、日志工具这些边角也不能放过
除了上面几个大头，还有几个命令值得顺手配一下。less 查看带 ANSI 颜色的文件时，如果不加-R，颜色转义码会原样显示成^[[31m这种乱码。给 less 设个 alias：
alias less='less -R' alias more='less -R'tree命令自带的--color参数在很多发行版里默认启用，如果你发现你的tree输出是纯色的，试试tree --color，或者检查LS_COLORS是否正常，因为 tree 会读取它。
还有一个容易被忽略的是journalctl，从 systemd 取日志时默认就会根据日志级别上色，emerg红色、warning黄色。出现“journalctl 输出没颜色”的情况，同样先查TERM和输出是否被管道接走。日志排错时让关键级别有颜色，能让你在一堆日志里快速锁定 panic、error、warning，这个收益是实打实的效率提升。
5. 更体面的方案：用 tput 替代硬编码转义序列
5.1 硬编码方案的问题出在哪
前面我们用的都是\e[31m这种硬编码转义码，好处是直观，坏处是它写死了“终端一定支持 ANSI 颜色”。大多数现代终端模拟器都支持，但总有不支持的场景：比如你 SSH 到一台很老的设备、或者某些串口终端、又或者TERM=linux但颜色支持不完整的控制台。在这些场景下硬编码的颜色要么不生效，要么直接显示成乱码。
另外一个问题是维护性。你把\e[1;32m写得到处都是，后面想统一改个颜色，得全局替换；如果不小心漏了一个、或者属性顺序写错，排查起来非常费劲。tput是另一个思路：它去查询系统的 terminfo 数据库，根据TERM变量动态生成正确的转义序列。简单说，你告诉它“我要绿色、我要加粗”，它自动算出当前终端该输出什么。
5.2 tput 的基本用法和回退策略
tput 的基本用法是：
tput setaf 2 # 设置前景色为绿色（0-7 对应黑红绿黄蓝紫青白） tput setab 4 # 设置背景色为蓝色 tput bold # 开启加粗 tput sgr0 # 重置所有样式把tput塞进字符串里，就能得到一份“自适配”的颜色方案。比如：
GREEN=$(tput setaf 2) BLUE=$(tput setaf 4) RESET=$(tput sgr0) echo "${GREEN}成功${RESET}，${BLUE}继续${RESET}"如果你的终端不支持 256 色，tput setaf 2依然会输出一个可用的绿色，因为它查询的是 terminfo 数据库，这个库知道当前终端该用哪种方式表达绿色。tput在脚本里还有个好处：你可以先检查tput colors的返回值，如果它返回小于 8，说明终端连基本颜色都不太行，那就干脆别用彩色。
在 PS1 里也可以这样玩，虽然看起来不如硬编码直观，但胜在兼容性好：
export PS1="\[$(tput bold; tput setaf 32)\]\\u\[$(tput sgr0)\]@\[$(tput setaf 34)\]\h\[$(tput sgr0)\]:\w$ "注意tput输出的转义序列本身不带\[标记，所以你在 PS1 里还是要手动包上\[和\]，不然又会出现光标错位问题。
5.3 用 tput 写一个带颜色输出的 shell 函数
在实际运维脚本里，我特别推荐用 tput 封装几个带颜色的 echo 函数，把日志打点做成统一的风格。下面是我很喜欢的一套模板：
if [ -t 1 ] && [ "$(tput colors)" -ge 8 ]; then C_GREEN=$(tput setaf 2) C_YELLOW=$(tput setaf 3) C_RED=$(tput setaf 1) C_RESET=$(tput sgr0) else C_GREEN="" C_YELLOW="" C_RED="" C_RESET="" fi info() { echo "${C_GREEN}[INFO]${C_RESET} $*"; } warn() { echo "${C_YELLOW}[WARN]${C_RESET} $*"; } error() { echo "${C_RED}[ERROR]${C_RESET} $*"; }这个函数设计有一个很关键的点：它先判断了输出是不是终端（-t 1），如果不是终端，比如脚本被 cron 调用、输出进了日志文件，那颜色变量就是空字符串。这样一来，脚本的日志在终端里看五颜六色，落盘时是纯文本，避免日志文件里出现一堆转义码。
很多人在脚本里直接写死颜色，最后日志文件里全是^[[32m，排查问题的时候还以为是内容被污染了。用 tput 加-t判断这个组合，就能从根本上避免这个烦恼。
6. 常见问题排查：颜色倒是配了，结果全乱了
6.1 提示符上出现 ^[[01;32m 这种乱码
这是最经典的“颜色事故”。你配置完.bashrc之后提示符不是变成绿色，而是直接显示一长串^[[01;32m加^[[0m。这个^[其实不是一个脱字符加一个方括号，而是 ESC 字符在终端上的可视化表示——终端没能把它解释成控制序列，而是当成普通字符显示出来了。
出现这种情况，90% 的原因是PS1里的转义码没有被正确包裹，或者PS1里写了\033但 bash 解析PS1时不会把\033展开成 ESC。在PS1中，\e和\[、\]是 bash 自己特殊处理的序列，不是读环境变量时的普通字符串展开。如果你在.bashrc里写export PS1="\e[32m\u\e[0m\$"，这样是没问题的，因为 bash 解析PS1时会把\e变成 ESC。但如果你在别的语言里输出PS1或者用了printf去拼，就很容易把转义码“展平”成字面字符。
解决方法很简单：先echo "$PS1"看内容，如果里面出现的是\e而不是实际的 ESC，问题就出在赋值方式上；如果内容里就是裸的[01;32m，那是缺少了\e前缀。总之，回到.bashrc用标准的export PS1="\[\e[1;32m\]...\[\e[0m\]"方式，基本不会再出问题。
6.2 本机有颜色，SSH 上去就没了
本地终端颜色一切正常，SSH 到某台新机器之后，提示符、ls 输出全变成黑白。这个问题的排查顺序很有讲究。
首先看TERM。SSH 客户端会把你本地的TERM传给远端，如果远端没有安装对应的 terminfo 条目，系统会把TERM降级成dumb或者unknown，程序一看这种 TERM 就不给颜色了。验证方法：SSH 登录后echo $TERM，如果是dumb或者unknown，手动export TERM=xterm-256color试试，有颜色了就说明是这个原因。
第二个原因是远端机器的~/.bashrc里压根没有加载颜色配置。很多发行版会把PS1的定义放在/etc/bashrc，但有些精简系统或者容器镜像默认是PS1='\s-\v\$ '，也就是我们开头看到的bash-5.1$。这种情况直接在那台机器的.bashrc里加入我们前面的配置即可。
第三个原因是su切换了用户。你用普通用户 SSH 登录，然后su root，此时 root 的环境变量会重新初始化，如果你之前只是改了普通用户的.bashrc，root 那边自然没有你的颜色配置。
6.3 root 的配置不生效，先分清 su 和 su -
“我给 root 配了红色提示符，但 su 过去之后还是原来的样子”这个问题高频出现。关键在于su和su -的区别：
su root：只切换用户身份，保留当前 shell 的环境变量、PS1、当前目录等大部分状态。su - root：模拟一次完整登录，重新读取目标用户的/etc/profile、~/.bash_profile、~/.bashrc。
所以如果你用su -登录 root，理论上会读取 root 的.bashrc，里面如果写了红色 PS1 就会生效。如果你用su登录，你继承的还是原用户的环境，root 的.bashrc可能根本没被读。这就是很多人疑惑“我明明改了 root 的 .bashrc 但就是不生效”的原因。
另外检查一下 root 的~/.bash_profile是否加载了.bashrc。有些系统 root 的~/.bash_profile里没有那段if [ -f ~/.bashrc ]的判断，导致.bashrc根本没执行。手动在 root 的~/.bash_profile加上[ -f ~/.bashrc ] && . ~/.bashrc一般就能解决。
6.4 管道和重定向里颜色凭空消失
这个问题不是故障，而是“预期行为”。前面提到过--color=auto的设计目标就是只在终端输出时加色。如果你grep error app.log > result.txt，里面不会有颜色；如果你ls | grep xx，ls 的输出不带颜色。这是为了避免污染下一级消费者。
但有时候你就是想在文件里保留颜色，比如导出带高亮的报告给同事看。此时可以使用--color=always：
grep --color=always error app.log > report.txt然后用less -R report.txt查看，颜色会被保留。注意如果不加-R，less会原样显示转义码，报告反而难看。
在 shell 脚本里如果发现自己“明明写了颜色，但重定向到文件后怎么全是乱码”，请检查是不是用了硬编码的\e[31m输出到文件。这种情况下应该用我们前面 tput 那套方案，先判断-t 1再决定是否输出颜色。
6.5 颜色配置问题快速排查表
| 症状 | 可能原因 | 处理方式 |
|---|---|---|
| 提示符显示 ^[ 乱码 | PS1 中转义码未被正确解析 | 用标准\[\e[1;32m\]...\[\e[0m\]重新赋值 |
| ls 完全没颜色 | alias 没配置 ls --color=auto | 检查并添加alias ls='ls --color=auto' |
| 目录颜色不对 | LS_COLORS 缺失或 TERM 不支持 | 设置LS_COLORS，检查TERM |
| SSH 过去颜色全丢 | TERM 被降级或远端无配置 | export TERM=xterm-256color，补配置 |
| root 提示符没变 | su 和 su - 混淆，或 .bashrc 未被加载 | 使用su -，确认加载.bashrc |
| 重定向文件满是 ^[ | 用硬编码颜色且未判断终端 | 用 tput +[ -t 1 ]方案 |
| 颜色突然“剥落” | 输出经过过滤器 | 用--color=always/less -R组合 |
| vim 颜色很淡 | 未开 termguicolors 或 t_Co 不足 | 设置set t_Co=256/set termguicolors |
最后分享一个我自己的心得：配颜色最忌讳一次贪多。很多人拿到配置模板以后，PS1、LS_COLORS、grep、vim 全部一把梭贴进去，结果出了问题根本不知道是哪一块引起的。我的建议是每次只改一个点，改完立刻在当前会话验证，确认没问题再动下一个。另外，把这份颜色配置纳入你的 dotfiles 仓库，换机器的时候直接克隆下来source一下就能恢复习惯，省得每次新开环境都从头调一遍。如果你还想继续玩下去，可以把 git 分支信息、当前 Python 虚拟环境名字放进 PS1 里，再配合终端真彩色，整个命令行体验基本就到第一梯队了。
