如果你每天要在 Linux 终端里泡上几个小时，命令行颜色这件事绝对不是锦上添花的小事。打开终端看到的ls输出清一色黑底白字，或者 SSH 到服务器后所有文件都长一个样，识别效率会低到你怀疑人生。我在刚接触 Linux 的那阵子，就一直困惑为什么别人的终端里有绿色、蓝色、青色的文件列表，而自己的ls输出永远是一团黑白色。后来花了点时间把LS_COLORS、PS1、dircolors这些东西理清楚，才发现这一层颜色配置并不复杂，但确实需要从原理上弄明白。

这篇文章主要是写给两类人：一类是想把本地开发机终端配色调舒服的初学者，另一类是经常登录服务器、被默认黑白色折磨的运维或后端开发。我会从颜色代码的基本原理讲起，再把ls、Bash 提示符、grep这些高频命令的配色方案一个个拆开，最后附上我自己踩过的几个坑。目标是你看完以后，不需要复制粘贴一大坨自己看不懂的字符串，也能写出适合自己的配置。

1. 命令行颜色到底在管什么：先认清三个层面

1.1 终端的颜色不是“一个开关”决定的

很多人以为终端颜色就是设置里换一个主题的事，其实在 Linux 下，命令行颜色至少由三层决定：

• 终端模拟器本身：比如你用的是 GNOME Terminal、Konsole、Windows Terminal 还是 macOS 的 Terminal.app，它们管理的是字体、背景、以及默认的 16 色配色板。
• Shell 提示符（PS1）：这个决定命令行输入光标前那一段提示文字长什么样。
• 命令输出的颜色：比如ls对目录、可执行文件、压缩包染上不同颜色，grep对命中关键词高亮，vim对语法元素着色。

这三层各管各的，互相独立，但也可能互相干扰。有时候你觉得“颜色没生效”，其实不是没生效，而是你改的那个变量只影响其中某一层。比如你把PS1改了，但ls的颜色依然白底黑字；或者你在终端设置里换了主题，但vim的语法高亮还是靠 vim 自己的配置。

所以在动手之前，先想清楚你当前要解决的是哪一层的问题。我把这个理念放在最前面，是因为后面的所有操作都建立在“明确目标层”这个基础上。

1.2 为什么默认配置总是不够用

各大发行版的默认终端配置通常会开启ls的基础颜色，但也仅此而已。比如 Ubuntu 的默认.bashrc里会调用dircolors生成一个基础LS_COLORS，目录是蓝色，可执行文件是绿色，压缩包是红色，这些基础色能用，但存在一个明显问题：蓝色在黑色背景的终端里识别度并不高，而且不同文件类型的区分度很低。

还有一类更麻烦的情况：你通过 SSH 登录一台精简服务器，发现所有输出都是单色。原因是很多服务器默认只设置了TERM=xterm，但没有安装dircolors，也没有加载任何颜色相关的 shell 配置。此时你看到的不是“配置坏了”，而是“本来就没有配置”。

理解这一点后，你就知道为什么要自定义颜色——不是为了让终端变得花哨，而是为了减少扫视文件列表时的认知负担。合理的配色应当让“目录、普通文件、可执行文件、软链接、压缩包”在 0.5 秒内被区分出来，而不是让眼睛逐个去辨认。

1.3 颜色代码的底层原理：SGR 转义序列

所有终端颜色最终都通过 ANSI 转义序列（ECMA-48 里的 SGR 参数）来实现。说人话就是：终端遇到\033[31m这样的字节序列时，会把后续文本显示为红色，遇到\033[0m时恢复默认。

\033是 ESC 字符的八进制写法，[是控制序列引导符，31表示前景色红色，m表示执行 SGR 命令。常见的 SGR 参数如下：

• 前景色：30 黑、31 红、32 绿、33 黄、34 蓝、35 紫、36 青、37 白
• 背景色：40-47，对应同样的颜色顺序
• 样式：1 加粗、4 下划线、5 闪烁、7 反显（交换前景背景色）

比如\033[1;32m就是粗体绿色。分号分隔多个参数，最后以m收尾。这个原理决定了后面所有配置项的本质：无论是LS_COLORS里的di=01;34，还是PS1里的\[\e[32m\]，最后都是拼成一段 SGR 序列交给终端。

理解了这个，你就不容易被网上那些魔法字符串吓到。它们不是随机的数字堆砌，只是把参数按规则组合而已。

2. 设置 ls 文件类型颜色：dircolors 与 LS_COLORS 详解

2.1 先跑一条命令，让 ls 立刻带上颜色

如果你的系统里没有开启任何ls颜色，最快的验证方式是在当前 shell 执行：

eval "$(dircolors -b)"

dircolors会读取一个配置文件（默认是/etc/DIR_COLORS），生成一组 Shell 命令，eval会把它们加载到当前环境。-b表示输出兼容 bash 的语法。执行完成后，ls的输出就会带上颜色。

如果系统里没有dircolors（某些精简环境没有安装 coreutils 的工具集），你可以直接设置ls的别名：

alias ls='ls --color=auto'

--color=auto表示在输出到终端时启用颜色，但输出被重定向到文件或管道时自动禁用颜色，这个选项非常适合日常使用。手动测试时也可以直接用ls --color=always，但这里有个坑后面会细说。

2.2 手工编写 LS_COLORS 字符串

LS_COLORS是一个环境变量，里面用冒号分隔多个键值对。每个键是一个文件类型标识，值是一组 SGR 参数。我常用的几个键：

• di：目录
• fi：普通文件
• ln：软链接
• ex：可执行文件
• *.tar这类通配符：按扩展名匹配的文件

一条典型的LS_COLORS配置长这样：

export LS_COLORS='di=01;34:ln=01;36:ex=01;32:*.tar=01;31:*.zip=01;31'

含义是：目录用粗体蓝色，软链接用粗体青色，可执行文件用粗体绿色，tar 和 zip 压缩包用粗体红色。注意这里用01;34而不是34，是因为加粗可以让颜色在高亮背景下更容易辨认，尤其在深色终端里。

如果想更精细地调整，可以把配置放在单独的文件里。先导出一份默认配置作为模板：

dircolors -p > ~/.dircolors

然后编辑~/.dircolors，找到对应条目修改即可。改完以后用：

eval "$(dircolors -b ~/.dircolors)"

加载自定义配置。这个文件里的注释非常详细，每个键是什么意思都写得很清楚，强烈建议第一次配置时看一眼。

2.3 如何让它开机自动生效

光是执行一次eval是不够的，你需要把加载动作写进 shell 启动文件。以 bash 为例，在~/.bashrc末尾添加：

if [ -x /usr/bin/dircolors ]; then if [ -f ~/.dircolors ]; then eval "$(dircolors -b ~/.dircolors)" else eval "$(dircolors -b)" fi fi

如果不会生成~/.dircolors，就只保留 else 分支，走系统默认配置。这样每次打开新终端，或 SSH 登录时，ls的颜色都会自动加载。

有一个细节很多人会忽略：dircolors生成的命令里包含export LS_COLORS=...，所以你自己在配置里再写一次export LS_COLORS=...会把它覆盖掉。正确做法是把自定义的LS_COLORS字符串直接放到~/.dircolors文件里，或者通过eval "$(dircolors -b ...)"来加载，二者只能选一种，不要混着写。

2.4 调整目录、可执行文件和软链接颜色的实例

拿我自己的配置举个例子。我习惯把目录设置成高亮蓝色加粗，这样在深色背景下不会和普通文本混淆；软链接用青色，因为软链接是“指向别处”的东西，青色在终端里感知度最高；可执行文件用绿色加粗，压缩包用红色加粗。

di=01;34 ln=01;36 ex=01;32 *.tar=01;31 *.gz=01;31 *.zip=01;31 *.7z=01;31

在~/.dircolors里，直接把di、ln、ex所在行的值改成上述参数，并在文件底部新增扩展名匹配规则。需要注意，扩展名规则是区分大小写的，*.Zip和*.zip是两条不同规则，如果希望统一处理可以写两条，或者用*.ZIP。

另外还有一个容易忽略的键：or（指向不存在目标的软链接）。这个建议单独设置成红色加粗，比如or=01;31，因为断链往往意味着部署或迁移出了异常，让它在列表里一眼暴露出来很有价值。

2.5 误区和坑：为什么改了没效果

我见过的第一个误区是在~/.bashrc里直接写export LS_COLORS="di=01;34..."，又同时保留了发行版默认的eval "$(dircolors -b)"。由于后者会在 shell 启动时被后执行，会把前者的值覆盖掉，结果就是你明明改了却看不到变化。

解决办法是统一入口：要么只编辑~/.dircolors，要么在~/.bashrc里删掉原来的eval行，只留自己的export。我个人更推荐~/.dircolors方案，因为它的语法更可读，而且当你想知道某个文件类型对应哪个键时，直接翻注释就行。

第二个坑是LS_COLORS没导出。如果你只在函数内部设置了LS_COLORS，外部命令ls是读不到它的。也就是说，在.bashrc里直接写LS_COLORS='...'而不带export，对子进程不生效。dircolors -b生成的命令里自带export，所以很少踩到这个，但手写时容易忘。

第三个坑是ls本身没启用颜色。就算LS_COLORS配置得再漂亮，如果你的ls命令没有加--color参数，颜色根本不会输出。这也是为什么一定要配上别名alias ls='ls --color=auto'。你可以在交互式 shell 里通过type -a ls检查当前别名是否生效。

3. 定制 Bash 提示符 PS1：让命令行不再一片白

3.1 PS1 颜色转义的基本写法

PS1是 Bash 用来生成主提示符的变量。它里面可以包含普通文本、命令替换、用户名、主机名、当前目录等信息，也可以包含颜色转义。在 bash 里，颜色代码有两种主流写法：

export PS1='\[\e[32m\]\u@\h:\w\$\[\e[0m\] '

这段配置的意思是：用户名\u、主机名\h、当前目录\w和提示符符号\$，全部用绿色显示，最后\e[0m恢复默认色。\[和\]是 bash 专用的标记，用来告诉 shell 这两个括号之间的内容是不占显示宽度的转义序列，这样行宽计算才准确。

另一种写法是用\033代替\e：

export PS1='\[\033[32m\]\u@\h:\w\$\[\033[0m\] '

两者的效果完全一样，\e和\033都表示 ESC。具体用哪个取决于你的习惯，没有好坏之分。

3.2 拆解一个常用配置

来看一个我日常在用的配置：

export PS1='\[\e[1;32m\]\u@\h\[\e[0m\]:\[\e[1;34m\]\w\[\e[0m\]\$ '

拆开看：

• \[\e[1;32m\]：粗体绿色，作用于后面的用户名和主机名
• \[\e[0m\]：恢复默认，影响冒号之前的内容
• \[\e[1;34m\]：粗体蓝色，作用于当前目录
• \[\e[0m\]：再一次恢复默认
• \$：普通用户显示$，root 显示#

这样配置的好处是提示符里不同信息区块的颜色区分明显：用户名和主机名一眼可见，当前工作目录用了高对比度蓝色，命令输入处恢复默认色，不会因为颜色堆积影响阅读。

如果你是 root 用户，可以考虑把颜色改成红色系，因为 root 权限下误操作风险更高，用红色提示符能时刻提醒你当前身份。一个常见做法：

if [ "$EUID" -eq 0 ]; then export PS1='\[\e[31m\]\u@\h:\w#\[\e[0m\] ' else export PS1='\[\e[32m\]\u@\h:\w$\[\e[0m\] ' fi

3.3 在提示符中显示 Git 分支并着色

对于经常在 Git 仓库里操作的人来说，提示符里显示当前分支非常实用。我一般这样写：

__git_branch() { git branch --show-current 2>/dev/null } if [ -n "$(__git_branch)" ]; then export PS1='\[\e[1;32m\]\u@\h\[\e[0m\]:\[\e[1;34m\]\w\[\e[0m\] \[\e[1;35m\]$(__git_branch)\[\e[0m\]\$ ' fi

这里把分支信息放在目录后面，用紫色表示，和其他信息隔离。实际使用中要注意，每次生成提示符时都会执行一次git branch --show-current，在超大仓库里可能会有轻微延迟。如果在意性能，可以把命令改为只在目录变化时执行一次，或者用更简单的解析方式。

不过这个功能跟主题“命令行颜色”的关系是锦上添花，新手可以先跳过，等 PS1 基础配置稳定后再加。

3.4 小心 [ 和 ] 导致的光标错乱

这是定制 PS1 时最容易犯的错误。如果颜色转义没有被\[和\]包裹，bash 会把转义序列当成可见字符计算行宽，结果就是：输入长命令时，光标在终端里出现错位，按退格也可能跳错位置。

所以只要 PS1 里用了颜色转义，就必须把每个转义序列都包在\[和\]里。上面例子里的写法是最标准的，不要漏掉任何一个反斜杠方括号对。很多网上的配置看起来能显示颜色，但省略了\[和\]，一旦命令行超过终端宽度就会现出原形。

另外，PS1要用单引号而不是双引号来定义。单引号里的\e、\u、\w会被 bash 在每次生成提示符时解释，而双引号会在定义变量时直接展开，导致\u变成固定的用户名、\w变成当时的目录，失去了动态效果。

3.5 用 tput 替代硬编码转义

如果你不想记\e[32m这种转义序列，可以用tput命令来获取颜色代码。比如：

green=$(tput setaf 2) bold=$(tput bold) reset=$(tput sgr0) export PS1="\[$bold$green\]\u@\h\[$reset\]:\w\$ "

tput setaf 2返回绿色前景色的转义序列，tput sgr0返回重置样式。这种写法的优势是可读性更高，不再依赖颜色数字的记忆；缺点是每次打开 shell 都要额外执行几次外部命令，但在 PS1 长度有限的情况下性能影响可以忽略。

我还见过有人用tput快速检验颜色编号对应的效果：

for i in {0..255}; do printf "\033[38;5;%dm %3d \033[0m" "$i" "$i" [ $((i % 16)) -eq 15 ] && printf "\n" done

这个循环可以列出终端支持的所有 256 色，方便你挑选提示符里想要的颜色编号。

4. 让其他高频命令也带上颜色：grep、vim、ls 之外

4.1 grep 关键字高亮的配置

grep默认输出不带颜色，但它支持--color参数。在.bashrc里加一个别名是最省事的：

alias grep='grep --color=auto' alias egrep='egrep --color=auto' alias fgrep='fgrep --color=auto'

--color=auto的语义和ls一样：输出到终端时才有颜色，重定向到文件时没有颜色，避免在日志文件里混入转义字符。

如果觉得默认的红色关键字在部分背景下看不清，可以调整GREP_COLORS环境变量。比如我想让命中的字符显示粗体黄色、背景黑色，可以设置：

export GREP_COLORS='ms=01;33:fn=36:ln=32:se=30;47'

• ms：匹配到的文本
• fn：文件名
• ln：行号
• se：分隔符

实际效果是：文件名青色、行号绿色、匹配文本黄色加粗。这套配置对代码搜索和日志分析都很友好。

4.2 vim 语法高亮与主题选择

Vim 的颜色分为两层：终端颜色和语法高亮。先确保在~/.vimrc里有：

syntax on set termguicolors

set termguicolors让 vim 使用终端模拟器提供的真彩色（24-bit color），这样比你手动设置 256 色更平滑。如果你的终端不支持真彩色，可以注释掉这一行，vim 会自动回退到 256 色模式。

选择配色主题时，我建议先在终端里看一遍几个主流主题的实际效果。比如你可以在~/.vimrc里写：

colorscheme desert

或者安装第三方主题后通过colorscheme <name>切换。一个容易被忽略的点是：vim 会读取$TERM来决定是否输出颜色。如果TERM被设置成dumb或者没有正确识别，语法高亮会失效。用 SSH 连接时尤其常见，一般建议export TERM=xterm-256color。

4.3 man 和 less 的配色

看 man 手册时，默认的标题和关键字其实也有颜色控制，只是很多发行版没有配置。你可以用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[1;33m' export LESS_TERMCAP_se=$'\e[0m'

把这几行放到.bashrc里后，man手册里的粗体关键字会变成红色加粗，章节标题会变成蓝色加粗，醒目程度提高不少。

这里要注意：less的配色走的是 termcap 机制，用的是LESS_TERMCAP_*环境变量，而不是LESS本身。网上有的教程让改LESS里的颜色选项，那是错误的，less本身只管理分页显示，颜色由终端控制序列决定。

4.4 终端模拟器背景色对颜色的影响

即使所有配置都正确，最终呈现效果还取决于终端模拟器的配色板。同一个LS_COLORS里的34（蓝色），在深色背景终端和高亮背景终端里的可读性完全不同。

我习惯把终端背景设为深色，字体使用等宽字体，并开启字体抗锯齿。原因是深色背景下，亮色前景的对比度更高，颜色区分更明显。如果你偏爱浅色背景，则要把前景色的编号整体调深一档，比如把目录的34改成更深的蓝色，否则肉眼很难分清。

另外，不同终端模拟器对 16 色默认色的定义有差异。GNOME Terminal 和 Windows Terminal 的蓝色可能不是同一个色值，因此你在本地调好的颜色，换一个终端模拟器后效果可能发生变化。如果追求一致，可以在终端设置里自定义 16 种基础色板，这样所有命令颜色都会跟着统一。

5. 常见问题排查与实操技巧

5.1 颜色没生效的排查顺序

碰到颜色不生效，我一般按下面的顺序排查：

1. 先确认当前 shell 是否支持颜色输出：echo -e "\033[31m红色\033[0m"，如果输出里没有红色，问题多半在终端模拟器而不是 shell 配置。
2. 确认ls别名是否生效：执行type -a ls，看是否有alias ls='ls --color=auto'，如果没有，补充 alias。
3. 确认LS_COLORS是否被导出：执行env | grep LS_COLORS，如果结果为空，说明变量没有进入环境。
4. 确认配置加载顺序：某些系统里.bashrc里也有默认的eval "$(dircolors -b)"，如果你同时自定义了LS_COLORS，要确保后者生效。

这个顺序能屏蔽掉绝大多数“改了没反应”的情况。最容易出问题的往往是第 1 步，因为很多人直接改配置，却忽略了终端模拟器本身。

5.2 SSH 远程颜色丢失

SSH 登录远程服务器时，常见的颜色丢失原因有两种：一种是远程 shell 的配置没有加载颜色相关的别名和变量；另一种是TERM环境变量不对，比如变成了dumb，导致命令自动放弃输出颜色。

对于第一种，需要在远程机器的~/.bashrc里也写上一份颜色配置。对于第二种，可以在本地 SSH 命令里强制指定终端类型：

ssh -t user@host "export TERM=xterm-256color; bash"

-t会给远程 shell 分配一个伪终端，配合export TERM=...就能让远程命令认为自己在真实终端里运行。这个方法的缺点是每次都要手动指定，更好的做法还是在远程的~/.bashrc里固定TERM。

还要提醒一下：很多服务器为了性能，不会默认安装完整的 coreutils 配置，dircolors可能不存在。此时就算配了LS_COLORS也没用，因为ls可能来自精简版工具集，不认识这个变量。解决方法是安装标准 coreutils，或者直接用alias ls='ls --color=auto'来兜底。

5.3 想快速统一配置的小技巧

如果你在多台设备间同步配置，不要在每个终端里手工复制配置文件。我建议把颜色配置单独抽成一个文件，比如~/.shell-colors.sh，然后在.bashrc里source它：

source ~/.shell-colors.sh

这样所有颜色定义都集中在同一个文件里，修改时只改一处。如果使用 zsh，也可以在.zshrc里同样 source，兼容性很好。

另一个技巧是给ls的类别颜色做一个区分原则：颜色只用来区分“类型”，不要用来表达“重要性”。比如所有普通文件保持默认色，目录统一蓝色，可执行文件统一绿色，压缩包统一红色。当颜色遵循一致的规则时，扫视输出会非常快；反之如果颜色五花八门，反而增加大脑负担。

5.4 性能与可维护性的权衡

有些教程喜欢在提示符里做非常复杂的颜色逻辑，比如根据上一条命令是否出错而改变颜色。这类功能虽酷，但会让 PS1 变得很长，每敲一个回车都要执行多条子命令，在低配服务器上能明显感觉到延迟。

我的建议是：提示符颜色控制在两到三种颜色以内，动态信息用命令替换时注意是否每次都执行外部命令。如果你真的想实现出错变色，可以用：

PS1='\[\e[0;32m\]\u@\h\[\e[0m\]:\w\`if [ $? -eq 0 ]; then echo -e "\[\e[0m\]$"; else echo -e "\[\e[31m\]$"; fi\` '

但这个写法既难维护又容易踩引号转义的坑，我实际使用中发现没必要。把颜色作为一种静态信息标识，把出错显示交给命令本身的报错颜色，反而更直观。

5.5 从黑白色开始，一步一步来，别一次求全

最后分享一个实际操作中的体会：不要第一次配置就想把所有地方都换成花哨颜色，那样你很可能在 PS1 引号、LS_COLORS 覆盖、tput 转义这些环节里绕晕。建议按顺序来：

1. 先给ls配好一版稳定好用的颜色，跑上一周。
2. 再改 PS1，测试不同颜色组合的光标表现。
3. 最后再给grep、vim、man补充配色。

每一步都实际用几天，确认没有视觉疲劳和光标错乱，再进下一步。颜色配置的核心是让信息更快被读取，而不是展示你的终端有多炫。把高对比度、低认知负担放在第一位，其他都是次要的。

这一路配置下来，我对命令行颜色最大的体会是：真正好用的配色，往往不是最鲜艳的，而是能让你在 0.1 秒内分清目录、文件和可执行文件的配色。每个人的终端背景、显示器亮度、甚至个人对色彩的敏感度都不一样，所以别完全照抄别人的配置。找一个晚上，把.bashrc里的颜色变量改一改，打开终端看几眼，跑几条ls和grep，再微调几次，你就会找到属于自己的那套组合。这个折腾的过程本身，就是熟悉终端工作机制的最快方式。