1. 先从一次JDK环境变量配置失败聊起大约一个月前同事兴冲冲地跑来告诉我JDK 17 终于装好了环境变量也配上了java -version输出正常。我随口问了一句“你是写进哪个文件了”他说“/etc/profile啊教程里不都这么写的吗然后source /etc/profile。”我让他关掉终端重新开一个再试一下他敲完java -version屏幕上直接提示command not found。他当场愣住了“我明明配了环境变量为什么重启终端就失效”这句话我平均每个月都能听到一次。很多人对 Linux 环境变量的理解停留在“照着教程写几行到文件里然后 source 一下”的层面一旦遇到“改了不生效”“重启就丢”“只有某个终端能看到变量”这类问题就完全不知道从哪排查。这其实不是因为 Linux 环境变量有多玄学而是因为整个机制里有三个关键点经常被跳过配置文件加载顺序、登录 shell 和非登录 shell 的区别、以及export 的“单向传递”特性。这篇文章不打算讲那种“复制粘贴即可”的傻瓜教程而是想把你拉到环境变量的底层逻辑上把全局环境变量、局部环境变量、PATH 环境变量、数组变量这几个东西一次讲透。看完之后你会发现那些网上流传的“配置失败”案例基本都能自己定位了。2. 环境变量的底层逻辑局部与全局的边界在哪里2.1 shell变量和环境变量差的是一个export很多初学者刚接触环境变量时会有一个误解以为在终端里执行FOObar就是把环境变量设置好了。实际上你只是定义了一个shell 变量它只存在于当前这个 bash 进程里既不会被子进程继承也不会被其他终端看到。想要让它变成真正的环境变量必须执行export FOObar。这里有个很实用的实验你可以立刻在终端里验证# 终端1定义一个Shell变量不导出 FOOhello # 同一个终端里能看到 echo $FOO # 输出 hello # 启动一个子shell bash # 子shell里打印会发现FOO为空 echo $FOO # 输出空行更直观的验证方式是用env命令FOOhello env | grep FOO # 没有输出因为FOO还在shell变量里 export FOO env | grep FOO # 输出 FOOhelloexport干的事情本质上是把这个变量标记为“需要传递给之后创建的子进程”。注意是“之后创建的”如果你先启动了子进程再在父 shell 里 export这个子进程里永远看不到新增变量。这也是为什么在一个终端里 export 了变量另一个开着的终端不受影响——每个终端是一个独立的进程树环境变量只在创建子进程的那一刻被拷贝过去。2.2 从父进程到子进程的单向继承环境变量的传递是严格单向的父进程创建子进程时把自己的环境变量表复制一份交给子进程。子进程对这份拷贝做的任何修改都无法回传给父进程。这个概念听起来简单但实际工作中经常有人踩坑。比如我以前看到过有人在脚本里写了这样一段# test.sh export MY_ENV123 echo 脚本内设置了MY_ENV然后在终端执行./test.sh echo $MY_ENV # 输出为空执行脚本的时候./test.sh是启动了一个新的子进程脚本里的export只是修改了子进程的环境变量表。脚本执行完进程退出修改就跟着消失了。想要让脚本的修改影响当前 shell唯一的方式是用source或.来执行脚本让脚本在当前 shell 进程内运行source ./test.sh echo $MY_ENV # 输出 123这就是为什么我们去修改~/.bashrc、/etc/profile之后必须重新登录或者手动source才能生效——因为那些文件里的 export 需要在当前 shell 进程里重新执行一遍才会更新当前进程的环境变量表。2.3 所谓的“全局”其实只在进程树中成立英文里环境变量经常被分成global environment variable和local environment variable中文翻译成“全局”和“局部”。这个翻译其实有误导性。它并不是编程语言里那种“整个系统全局可见”的概念而是针对当前进程树来说的。一个变量被 export 之后它对这个 shell 以及它下面创建的所有子孙进程都是可见的看起来像“全局”。但只要走到这个进程树之外它就是不可见的。你在这个终端导出的变量另一个终端永远看不到你在用户 A 登录会话里导出的变量用户 B 登录之后也看不到。真正能做到“所有用户、所有会话”可见的只有写在系统级配置里的变量而且必须是在会话初始化阶段被加载。所以我想强调一个判断方法当你说“我要配置一个全局环境变量”时先问自己三个问题这个变量需要给哪些用户用当前用户还是所有用户需要给登录 shell 用还是包括非登录 shell是永久生效还是临时在当前会话里用一下这三个问题的答案基本就决定了你该把变量写进哪个文件或者需不需要 export。后面第五章我会详细展开配置文件的选择。3. PATH变量拆解命令查找的完整链路与修改姿势3.1 当你敲下ls时系统到底做了什么PATH 是 Linux 环境变量里最特殊、也最常用的一个。它不是某个软件需要的配置而是 shell 用来定位命令的查找路径。你可以把它理解成一张“门牌号列表”当你在终端输入一个命令名时shell 会按照 PATH 里目录的先后顺序依次去这些目录里找对应的可执行文件。echo $PATH输出可能是这样的/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin当你敲lsshell 先看/usr/local/sbin/ls是否存在不存在再看/usr/local/bin/ls不存在继续往后找直到在/usr/bin/ls或/bin/ls里找到然后执行它。如果所有目录都找不到就会提示command not found。这也解释了另一个常见问题为什么你明明安装了某个软件却提示找不到命令。要么是安装目录不在 PATH 里要么是你安装的命令名字和默认查找的路径不一致。还有一个很容易被忽略的点shell 会缓存命令的查找结果缓存在一个叫 hash 表的东西里。你用which ls找到的是/usr/bin/lsshell 记住之后下次直接从这个路径执行。如果你把新的可执行文件放到了 PATH 更靠前的目录shell 可能还记着老位置。遇到这种“明明加了路径重启也重启了还是执行老版本”的情况执行一下hash -r清空缓存往往就好了。3.2 修改 PATH 的几种方式以及各自的生效范围改 PATH 本质上就是重新给 PATH 这个变量赋值。最常见的需求是“追加一个新目录同时保留原有内容”写法是export PATH$PATH:/opt/mytool/bin这句话的意思是把原 PATH 的值取出来加上冒号再接上/opt/mytool/bin重新赋值给 PATH并导出。这里的冒号是 PATH 列表的分隔符和ls -l输出里的冒号没有半点关系。根据生效范围不同修改方式可以分成四类它们之间的区别我用一个表总结写法生效范围是否永久适用场景export PATH/opt/bin:$PATH当前 shell 及子进程否关闭终端失效临时测试某个工具FOObar command仅这一次命令否给单个命令传环境变量写入~/.bashrc当前用户所有交互 shell是个人常用工具路径写入/etc/profile或/etc/environment所有用户登录会话是系统级安装的软件路径这里特别想提醒一点很多教程喜欢让新手把路径追加到 PATH 末尾但我个人的习惯是如果我希望某个目录里的命令优先于系统命令就放到最前面比如export PATH/opt/mytool/bin:$PATH如果只是希望系统找不到的时候才去这个目录找就放到最后面比如export PATH$PATH:/opt/mytool/bin。这个顺序在你想“覆盖系统自带版本”的时候非常关键。3.3 追加 PATH 时最常见的三个坑第一个坑重复追加。每次 source 一次~/.bashrc都会往 PATH 里多追加一份。多 source 几次之后echo $PATH会看到一连串重复的路径。虽然一般不影响功能但会让排查问题变得很痛苦。如果你发现自己 PATH 里同一个目录出现了三五遍大概率是这个原因。第二个坑用相对路径。export PATH./bin:$PATH看起来是加了一个相对路径但 PATH 里的相对路径是相对于“当前工作目录”解析的。你在这个目录下命令能执行换一个目录就全部失效了。更危险的是如果 PATH 里有一个空字符串的项比如PATH:/usr/bin:/bin它等价于“把当前目录加入查找范围”如果你碰巧在一个被人放了恶意可执行文件的目录里敲ls命中的可能不是系统那个ls而是当前目录下的同名文件。所以在任何涉及权限的机器上我都不推荐把当前目录加进 PATH。第三个坑把 PATH 覆盖了。新手最容易犯的错误是直接写export PATH/opt/jdk/bin把原来那一长串路径全丢了。命令倒是能执行前提是你只敲绝对路径——因为这时候连ls、find都找不到了。一旦你登录之后发现“所有命令都消失了”不用慌用/bin/echo $PATH、/bin/ls这种绝对路径方式临时调用命令把 PATH 修复回去就行。4. 数组变量环境变量家族里最不受重视的工具4.1 数组的声明、追加和遍历聊环境变量的时候很少有人会把数组变量扯进来但 bash 里数组确实是个非常趁手的变量类型尤其是写脚本处理一组路径、一组 IP、一组文件名的时候。声明一个数组很简单# 用空格分隔元素 server_list(192.168.1.1 192.168.1.2 192.168.1.3) # 取出第0个元素注意bash数组下标从0开始 echo ${server_list[0]} # 取出所有元素 echo ${server_list[]} # 追加元素 server_list(192.168.1.4) # 遍历数组 for ip in ${server_list[]}; do ping -c 1 $ip /dev/null 21 echo $ip is up || echo $ip is down done这段代码里值得抠一下的是${server_list[]}外面那个双引号。如果你不加引号数组元素里有空格或特殊字符时会被 shell 重新分词加了双引号才能保证每个元素作为一个整体被传入循环。这一点在处理文件名时尤其重要比如file_list(my document.txt report final.doc) for f in ${file_list[]}; do echo 处理: $f done如果不写双引号my document.txt会被拆成my和document.txt两个元素程序就乱了。4.2 数组到底能不能导出为环境变量这个问题我查过不少次也做过实验。答案是可以导出但跨进程传递之后行为可能和你预期不太一样。在 bash 里执行export arr之后子 shell 中确实能看到这个变量但它在环境变量表里被存成了字符串形式和普通变量一样arr(a b c) export arr bash -c echo ${arr[0]}在一些 bash 版本里能正常输出a在另一些版本或 dash 里可能根本报错。这主要是因为环境变量本质上是一张“字符串键值对表”数组本身并不是 POSIX 标准里的类型。所以我的建议是不要依赖“导出数组”这个特性。如果你真的需要把一组数据传给子进程更稳的做法是折成字符串到子进程里再还原# 父进程把数组转成冒号分隔的字符串 export SERVER_LIST192.168.1.1:192.168.1.2:192.168.1.3 # 子进程脚本里按冒号拆分还原 IFS: read -r -a server_array $SERVER_LIST for ip in ${server_array[]}; do echo 目标: $ip done这种折字符串的方式还能规避“环境变量值里包含换行符”引发的各种怪问题。Linux 环境变量的值可以包含空格、下划线、数字但不建议把换行符放进环境变量里很多程序解析环境变量时根本没考虑过换行符的存在。4.3 使用数组处理脚本参数的真实场景数组在实际脚本里还有一个常见用法就是处理位置参数。你把所有参数收集到一个数组里再配合shift逐个消费。比如我写过一个批量部署脚本的开头# 把脚本的所有参数放到数组里 args($) # 第0个参数就是脚本名 echo 脚本名: ${args[0]}更常见的场景是配合shift做参数解析while [ $# -gt 0 ]; do case $1 in -h|--host) host$2 shift 2 ;; -v|--verbose) verbose1 shift ;; *) echo 未知参数: $1 exit 1 ;; esac done这里$在 bash 里其实就是一个“位置参数数组”只是它的下标从 1 开始$0是脚本名。搞清楚这一点之后你再看很多 shell 脚本里的“魔法”就不会觉得费解了。5. 配置文件加载顺序以及“改了不生效”的完整排查链路5.1 登录shell、非登录shell读的文件不一样回到开头同事的问题为什么写进/etc/profile之后新开的终端里java依然找不见因为 Linux 的 shell 分成了好几种形态每种形态启动时加载的配置文件不一样。常见的情况里一个用户打开终端绝大多数时候得到的是一个“交互式非登录 shell”它启动时不会读/etc/profile而是去读当前用户家目录下的~/.bashrc。这里把最常见的 Ubuntu、CentOS 系列 bash 行为整理一下Shell 类型启动时主要加载的文件交互式登录 shell/etc/profile然后按顺序读~/.bash_profile、~/.bash_login、~/.profile读到一个就停交互式非登录 shell/etc/bash.bashrc有的发行版然后读~/.bashrc非交互 shell脚本读取$BASH_ENV指定的文件未设置就不读所以在/etc/profile里配了 JAVA_HOME你执行ssh userhost这种登录式会话能看到但双击打开一个图形终端不一定会看到。正确做法是把用户级别的环境变量写进~/.bashrc如果要系统级生效写/etc/profile之余还得确认你的终端是不是登录 shell。另一个常见的坑是很多人在~/.bash_profile里配了环境变量但新建终端时根本不会加载这个文件。我见过一个特别典型的案例用户把 JAVA_HOME 写进了~/.bash_profile用 IDE 启动终端时能识别 Java直接开系统终端时却不行。原因就是 IDE 的终端模拟器启动的是非登录 shell不读~/.bash_profile。我通常建议“用户级环境变量优先写~/.bashrc”因为它覆盖的场景更广。5.2 不要忽略/etc/environment和其他底层入口除了上面那几个文件还有一个很多人不太熟的/etc/environment。它不是 shell 脚本而是一个简朴的“键值”文件由 PAM 在用户登录时读取并写入进程环境。它不执行命令、不支持 shell 变量展开但对于设置那种“整个系统从登录一开始就要看见”的变量很合适。不过它也有一些限制比如不推荐在里面写含有动态命令替换的内容。另外还有个容易被忽略的细节~/.profile和~/.bash_profile能不能加载~/.bashrc取决于文件里有没有显式写source ~/.bashrc。某些发行版的默认~/.profile里带了这段逻辑某些没有。所以你在~/.bashrc里加的东西登录 shell 里看不到很可能是你的~/.profile或~/.bash_profile里根本没有触发对~/.bashrc的加载。排查的时候别盯着一个文件看要沿着执行链一路看下去。5.3 一条完整的排查链路我现在遇到环境变量不生效的问题基本按照下面这条链路走一般都能定位确认变量在当前 shell 里有没有值echo $JAVA_HOME。查看它是怎么进来的type -a java可以看到命令解析路径env | grep JAVA查看环境变量表。判断当前 shell 类型echo $0如果输出的是-bash表示登录 shell如果是bash表示非登录 shell。模拟重新读取配置文件bash -l开一个登录 shell 验证再bash开一个普通子 shell 验证。分开排查系统配置和用户配置先grep -n JAVA /etc/profile /etc/environment再看~/.bashrc、~/.profile。注意文件的读取顺序如果同一个变量在多个文件里被赋值后执行的覆盖先执行的。例如~/.bashrc里的 export 会覆盖~/.profile里先加载的值。有一次我帮别人排查一个奇怪的“环境变量时有时无”的问题最后发现是他的~/.bash_profile里先 source 了~/.bashrc而~/.bashrc里又有[ -z $PS1 ] return这种针对非交互 shell 的短路逻辑导致某些场景下加载就被截断了。这种问题不看执行链单纯搜配置是搜不出来的。6. 脚本里的环境变量工程化实践与我的避坑习惯6.1 临时修改环境变量的三种正确姿势写脚本时经常要临时改变环境变量最常见的手段有三种。第一种是“脚本内部统一设置”在脚本开头用 export 设置好脚本结束自动废弃不影响外部环境。第二种是“临时给单条命令设置环境变量”语法是VARvalue command# 这条命令启动时能看到 MY_CONFIG命令结束后环境变量消失 MY_CONFIG/etc/myapp/config ./start.sh这种写法比“export 完再执行命令最后 unset”要安全得多不会污染当前 shell。第三种是用env命令显式指定环境变量适合你想清除某个变量或者批量设置多个变量的场景env -i PATH/usr/bin:/bin HOME/root ./start.sh-i表示从空环境启动把可控性拉到最满。在脚本里跑一些不太信任的程序时我经常会用这种方式严格控制它能看到的变量。6.2 带空格路径和特殊字符的处理环境变量的值可以包含空格但这不代表你在使用它的所有地方都得带引号。常见的问题是配置了一个带空格的路径比如MY_HOME/opt/My Softwares/App然后在脚本里写cd $MY_HOMEshell 会把它拆成两个词导致目录找不到。正确的写法是cd $MY_HOME。还有一个很容易被忽略的点环境变量名本身也有限制。POSIX 规范里环境变量名只能由字母、数字和下划线组成而且不能以数字开头。你写export 123abc大概率会报错但写export MY-APPabc在某些 shell 里可能不报错实际却无法正常传给子进程因为-会被当成减号操作符产生很隐蔽的 bug。所以我给自己定了一条规矩环境变量名一律用大写字母加下划线比如MY_APP_HOME。另外命令替换$(...)的值里如果有空格同样要用双引号包住。我在脚本里经常看到这样的写法# 错误示范当前目录名如果有空格目录就会不存在 export PROJECT_PATH$(pwd)# 正确示范 export PROJECT_PATH$(pwd)6.3 环境变量管理的三个小技巧最后分享几个我长期保留的环境变量操作习惯。第一用set -u防未定义变量。写 shell 脚本时在开头加上set -u任何引用到未定义变量的地方都会直接报错而不是静默地当成空字符串。环境变量拼写错了第一时间就能暴露出来而不是等到程序运行到一半才报一个莫名其妙的错。第二用单独的配置文件承载复杂环境变量。当环境变量特别多、变量值特别长时不建议全部堆在~/.bashrc里。我会写一个~/.env_custom在里面做各种 export然后在~/.bashrc里加一行source ~/.env_custom。这样改配置的时候只需要动一个文件而且万一出问题注释掉那一行就回到原样。第三修改重要变量之前先备份一行。尤其在调试 PATH 这类关键变量时我会先把原始值输出到一个临时文件echo $PATH /tmp/path_backup_$(date %F).txt这看起来像多此一举但真有几次我在调整 PATH 后把系统命令搞“丢”了全靠这个备份恢复。给自己留后路的习惯在 Linux 环境变量这个领域里永远不会多余。我在实际项目中见过太多环境变量配置问题归根结底都不是某条命令背不下来而是没搞懂环境变量的作用范围和加载链路。把“当前 shell”“子进程”“登录 shell 还是非登录 shell”这几点理解透了遇到问题时按着链路去排查比记住十个八个教程实在得多。