配 JDK 环境变量失败的那个下午我至今记忆犹新。当时刚把 Windows 上的 Java 开发习惯迁移到 Linux照着教程在终端里敲了export JAVA_HOME...又敲了export PATH$JAVA_HOME/bin:$PATH。java -version明明输出了版本号我放心地关了终端第二天再打开又是command not found。后来我才知道环境变量这个东西在交互式终端里用export设置是一次性的终端一关变量就没了。这篇文章就是我把整个 Linux 环境变量机制理清之后的个人笔记覆盖从登录 shell 到配置文件加载顺序、从 PATH 追加到排查链路、再到脚本子进程传递机制的全部内容适合被环境变量坑过、或者刚接触 Linux 想系统搞懂这套规则的读者。1. 先搞清楚export干了什么环境变量不是永久生效的东西很多教程一上来就让你export却不解释这句话的含义所以大部分人第一条命令就埋下了隐患。我在这里先把最基础的概念拆开。1.1 一次配置丢失的现场复盘我第一次配 JDK 时执行的是这两条命令JAVA_HOME/usr/local/jdk-18 export PATH$JAVA_HOME/bin:$PATH当时终端里一切正常java -version能打出信息。但关掉终端再打开配置就消失了。原因其实特别简单这些命令只对当前这个 shell 进程生效。Linux 的 shell 是一个进程你在里面敲的命令由这个进程的子进程执行当你退出终端shell 进程结束它维护的那张变量表随之销毁里面的配置全部归零。那为什么很多教程都这么写因为它们省略了一个前提这一段应该写进配置文件让每次启动 shell 时自动执行。我一开始没理解写在终端里和写在配置文件里是两回事就踩了坑。提示命令行里敲export只对当前会话有效想要持久化必须写入 shell 启动时自动加载的文本文件。1.2 shell 变量与环境变量的区别还有一个概念容易混淆shell 变量和环境变量并不是一回事。shell 变量只在当前 shell 进程内有效子进程拿不到。环境变量是经过export提升过的变量会进入进程的环境表被子进程继承。可以做个最简单的实验TEST_VARhello # 只是一个 shell 变量 echo $TEST_VAR # 输出 hello bash # 进入子 shell echo $TEST_VAR # 输出为空子进程里根本没有这个变量 exit export TEST_VARhello # export 提升为环境变量 bash echo $TEST_VAR # 输出 hello子进程继承了这个实验做完我对export 到底做了什么事就再也没疑问了。它本质上是把变量从当前 shell 的局部寄存表复制进当前 shell 的环境块而子进程启动时会从父进程的环境块拷贝一份。注意是拷贝不是共享——子进程改了环境变量不会反馈给父进程这点后面专门讲。2. 登录 shell 与非登录 shell90% 的配置没生效都出在这里我后来发现环境变量配置失败的案例里十有八九不是命令敲错而是把配置写进了错误的启动文件。这又要回到登录 shell 和非登录 shell 的区别。2.1 两类 shell 的唤醒路径Linux 的 bash 启动时会读取不同文件具体读哪个取决于它是不是登录 shell类型触发场景依次加载的文件登录 shellssh 登录、物理终端登录、su - user/etc/profile、~/.bash_profile、~/.bash_login、~/.profile按顺序读第一个存在的用户级文件非登录 shell打开一个新的终端窗口/标签页、bash命令进入子 shell/etc/bashrc或/etc/bash.bashrc发行版不同、~/.bashrc很多桌面环境下你打开终端模拟器运行的是非登录 shell所以它根本不读~/.bash_profile。我当初就是往~/.bash_profile里写配置在图形界面里开终端自然等于没写。反过来你通过 ssh 登录一台服务器时进入的是登录 shell它优先读~/.bash_profile如果这个文件里没有主动 source~/.bashrc那么~/.bashrc里那一堆配置就通通不会生效。不同发行版对这个衔接的处理还不一样有的默认帮你写好了有的没有。2.2 配置到底该写进哪个文件我的习惯是分三层全局面向所有用户写入/etc/profile.d/下一个自定义.sh文件例如/etc/profile.d/myenv.sh。系统加载/etc/profile时会自动 source 这个目录下所有.sh文件。这样做的好处是不直接改动/etc/profile主文件升级系统时不容易被覆盖。当前用户、面向所有 bash 会话全部写进~/.bashrc。然后确保~/.bash_profile或~/.profile里有这么一段if [ -f ~/.bashrc ]; then . ~/.bashrc fi这样无论从登录 shell 还是非登录 shell 进来配置都能加载。我遇到不少发行版默认~/.bash_profile就是这内容但有些精简镜像里没有需要自己补上。 3.只在桌面环境用、不希望 ssh 登录加载的内容可以放~/.profile或~/.xprofile但实际运维场景中我用得很少大多数时候交给~/.bashrc就够了。注意非登录 shell 不读.bash_profile登录 shell 可能不读.bashrc。想要两头兼顾就在.bash_profile里强制 source.bashrc。3. 配置文件加载顺序与常见安装包的配置方式理解了读哪个文件之后下一个问题是这些文件按什么顺序加载、互相之间怎么叠加。实际操作中很多奇怪现象都来自加载顺序。3.1 从系统开机到打开终端的加载次序以最常见的 CentOS/RHEL 系为例大致是这样一条链/etc/profile→/etc/profile.d/*.sh→~/.bash_profile→~/.bashrc→/etc/bashrcUbuntu/Debian 系的路径名略有差异比如用户级多了一个~/.profile/etc/bashrc被换成了/etc/bash.bashrc但结构类似。这条链有几个实际影响前面的文件定义的变量后面的文件可以用export VAR...覆盖。后面的文件能安全地追加PATH但前提是你没把 PATH 直接重新赋值覆盖掉。有些软件安装器比如 Anaconda会在~/.bashrc的末尾追加一段__conda_setup初始化脚本。为什么放末尾因为 conda 初始化要拿到前面已经定义好的 PATH 等变量才能做路径重排。如果安装器把这段插在文件开头而前面配置里又有export PATH/usr/local/bin这种覆盖操作conda 的配置就会被后面的覆盖冲掉导致conda: command not found或者base环境不激活。我实际见过一个问题用户在.bashrc中间配置了 Python 的虚拟环境和 conda把__conda_setup挪到了前面结果每次登录 shell active 到一半就报错。最后把 conda 初始化块挪回文件末尾才解决。这里的关键认知是配置文件不是简单的各行独立生效它本质上是按顺序被执行的 bash 脚本。3.2 JDK / Python / Anaconda / Maven 的典型配置写法结合最常见的几个安装包我给出实际用下来比较稳的写法。JDKexport JAVA_HOME/usr/local/jdk-17 export PATH$JAVA_HOME/bin:$PATH注意追加 PATH 时的$PATH写在后面是在变量的基础上往后加。如果你写export PATH$JAVA_HOME/bin等于把原来的 PATH 丢了那么ls、cp、vi这些基础命令立刻全挂因为它们的目录/usr/bin不在 PATH 里了。Python 自定义版本export PYTHON_HOME/opt/python-3.11 export PATH$PYTHON_HOME/bin:$PATHAnaconda 的初始化块通常是安装器自动生成的类似__conda_setup$(/opt/anaconda3/bin/conda shell.bash hook 2 /dev/null) if [ $? -eq 0 ]; then eval $__conda_setup else if [ -f /opt/anaconda3/etc/profile.d/conda.sh ]; then . /opt/anaconda3/etc/profile.d/conda.sh else export PATH/opt/anaconda3/bin:$PATH fi fi unset __conda_setup这段建议原样保留在~/.bashrc末尾。如果你在另外的地方也配了 conda 的 PATH可能会和这里冲突让 base 环境重复出现或者 conda 版本混乱。Mavenexport MAVEN_HOME/opt/maven-3.9 export PATH$MAVEN_HOME/bin:$PATH这几个配置本质上都是同一套路定义软件的根目录变量再把它的bin目录加到 PATH。理解了 PATH 的机制安装任何语言环境都是这一句话的事。4. PATH 的追加、去重与常用环境变量配置PATH 是环境变量里最常用、也最容易被配置乱的一个。这一节讲清楚它的机制再补充几个实际运维中同样重要的变量。4.1 防止覆盖 PATH 的稳妥写法PATH 的作用是告诉 shell当你在终端输入一个命令名时去哪些目录按顺序找对应的可执行文件。多个目录用冒号分隔。定位命令时依次遍历 PATH 中列出的目录一旦找到第一个匹配的就执行后面的目录不再看。这就引出一个现象同一个命令如果装在两个目录里PATH 中在前面的目录优先。所以配置 PATH 有一个核心原则只追加不覆盖尽量去重。常见的写法有几种。简单追加export PATH/opt/myapp/bin:$PATH如果想把新路径放到最前面优先使用export PATH/opt/myapp/bin:$PATH前面提到过覆盖式写法是灾难级的export PATH/opt/myapp/bin # 错误做法这条命令会把 PATH 变丢之后所有基础命令都找不到。如果已经这么做了还有救直接用绝对路径执行命令来恢复例如/usr/bin/export PATH/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin或者干脆重新登录。去重写法适合在.bashrc中重复执行而不产生冗余路径if [[ :$PATH: ! *:/opt/myapp/bin:* ]]; then export PATH/opt/myapp/bin:$PATH fi这一段的逻辑是检查当前 PATH 字符串里是否已经包含/opt/myapp/bin不存在才追加。:$PATH:这种写法是为了避免边界判断错误——比如 PATH 的开头或结尾没有冒号时子串匹配会出现误区。4.2 LANG、TMOUT、PS1、LD_LIBRARY_PATH 这些变量的意义除 PATH 之外下面几个变量在实际运维中出镜率很高变量作用常见坑LANG/LC_ALL决定程序显示语言和字符编码服务器上没设对日志出现乱码中文文件名处理异常TMOUT设置会话闲置秒数超时自动注销设置太短人离开一会儿就被退出PS1控制命令行提示符格式转义字符写错会显示异常LD_LIBRARY_PATH指定动态链接库的搜索路径不恰当使用可能导致程序链接到错误版本的库UMASK控制新建文件的默认权限掩码实际上是 shell 内建设错导致新建文件权限过宽HISTCONTROL/HISTSIZE控制历史记录大小与去重被安全基线要求修改时找不到位置LANG 特别值得多说一句。之前遇到过一台服务器上locale出现cannot set LC_CTYPE的报错排查半天发现是因为/etc/environment里设置了LANGen_US.UTF-8但系统根本没有生成这个 locale。解决办法要么是localedef -i en_US -f UTF-8 en_US.UTF-8手动生成本地化数据要么把 LANG 改成已安装的语言包。这类问题在最小化安装的镜像上非常典型。TMOUT 写进/etc/profile.d/timeout.sh可以做全局会话超时export TMOUT600但要注意这会让所有交互式会话 10 分钟无操作就被踢下线如果用户的终端挂着跑日志脚本会有明显体感。4.3 一份可以直接抄的 .bashrc 片段下面是我个人常用的.bashrc环境变量区做了注释读者可以直接改改路径拿来用# 语言环境 export LANGen_US.UTF-8 # 软件路径 export JAVA_HOME/usr/local/jdk-17 export MAVEN_HOME/opt/maven-3.9 export PYTHON_HOME/opt/python-3.11 # 追加 PATH for p in $JAVA_HOME/bin $MAVEN_HOME/bin $PYTHON_HOME/bin; do if [[ -d $p :$PATH: ! *:$p:* ]]; then export PATH$p:$PATH fi done # 提示符 export PS1\u\h:\w\$ # 定时清理 1 个月以上的 /tmp 临时文件非环境变量仅为示例收尾用 for 循环批量追加目录避免每个软件写三行重复代码也顺便做了去重检查。如果某个目录不存在-d判断会让它跳过这样即使暂时没装这个软件.bashrc也不至于报错。5. 一套可复现的环境变量排查链路环境变量配置出了问题最忌讳的是病急乱投医。我总结了几个固定步骤基本能在三分钟内定位到是哪一层的问题。5.1 先用三分钟定位哪一层出了问题第一步确认当前 shell 里变量到底有没有echo $PATH env | grep JAVA printenv JAVA_HOME如果终端里能看到说明配置本身已经加载完成了就不用再审配置文件如果看不到再进入下一步。第二步判断当前会话是登录 shell 还是非登录 shellecho $0输出如果是-bash带减号说明是登录 shell如果是bash是非登录 shell。这一点决定了去查哪个文件。第三步检查目标文件内容grep -n JAVA_HOME ~/.bashrc ~/.bash_profile /etc/profile 2/dev/null注意2/dev/null是为了屏蔽不存在的文件产生的报错信息避免噪音。第四步测试配置文件的语法bash -n ~/.bashrc如果这里没输出说明语法正常。有输出的话报错会直接指出是哪个文件第几行的什么原因。比如未闭合的引号、缺少空格、if/fi不配对都会在这里暴露。5.2 文件编码、换行符、缓存这类隐蔽原因前四步查完往往能解决大部分问题但还有几个隐蔽坑非常值得拿出来单独说。第一坑是Windows 换行符。如果配置文件在 Windows 上编辑过再传回 Linux每行末尾会带着\r。bash 在执行时把\r当成变量内容的一部分最常见的现象就是 PATH 末尾出现\r导致找不到命令。排查方法cat -A ~/.bashrc | grep JAVA_HOME如果看到JAVA_HOME^M$末尾的^M就是\r。批量清理可以用sed -i s/\r$// ~/.bashrc第二坑是命令哈希缓存。shell 为提高效率会缓存命令所在的路径。第一次执行某个命令时找到了位置之后如果你移动了二进制文件又忘了清缓存shell 还按旧路径找于是出现文件明明在却说 command not found。hash -r可以清空缓存type -a java可以列出 shell 认为 java 的所有来源路径。第三坑是发行版默认的 profile.d 脚本。某些系统会在/etc/profile.d/下放一堆环境初始化脚本它们可能在你配置之后又重新定义了 PATH。比如 Java 的 alternatives 机制有时会在/usr/bin/java做一个软链接如果你的 PATH 里既有/usr/bin又有$JAVA_HOME/bin实际执行哪个 java 取决于 PATH 顺序。遇到我配了 JAVA_HOME 但 java 还是老版本多半就是这个原因用type -a java一眼就能看出来。第四坑是.bashrc文件里有提前 return 或 exit。很多人会在.bashrc里写exit来快速断开某个会话但 bash 执行到exit后面的内容就不会再读了。排查时用bash -x ~/.bashrc跟踪执行过程能看到在哪一行停止。提示bash -x是很有意思的调试命令它会逐行打印执行过程配合PS4变量还能显示行号。我用它排查过不少诡异的启动问题比肉眼盯配置高效得多。6. 环境变量在脚本与子进程中的传递机制在前面提到过子进程会拷贝父进程的环境变量。这一节把这个机制展开因为它直接关系到写脚本时的变量传递问题。6.1 子进程只继承、不反向传递在终端里执行一个脚本、或运行一个前台程序时它都是你的 shell 的子进程。Linux 的进程模型决定了环境变量的流动方向只从父到子不从子到父。同一个终端里先后运行两个脚本前一个脚本设置的环境变量后一个脚本是拿不到的因为它们是兄弟进程而非父子进程即使真的是父子关系子进程里 export 的变量也不可能影响已经跑起来的父进程。所以如果你写了一个脚本里面设置了export FOObar运行完再 echo$FOO发现是空的这不是 bug是设计如此。想要让配置在当前 shell 里生效必须用source而不是直接执行。6.2 source、exec、export 的区别这里把几个容易混淆的执行方式梳理一下bash myscript.sh # 启动子进程执行脚本环境变量改动不影响父 shell . myscript.sh # source点命令在父 shell 进程内执行改动直接生效 source myscript.sh # 和 . 等价 exec myscript.sh # 用该脚本替换当前 shell 进程原 shell 不复存在一个典型场景是加载配置文件source ~/.bashrc很多人写成bash ~/.bashrc结果会话配置在子 shell 里跑完就消失了然后疑惑为什么 source 了还是没用。实际上他根本没 source。还有一类很有用的临时变量传递方式直接在命令前加前缀FOObar ./myscript.sh这个语法表示在启动 myscript.sh 的瞬间给它额外设置 FOObar不会污染当前 shell 的环境。这在调用一些需要特殊变量、但你又不想全局导出的程序时非常实用。env命令也常用来做类似的事env FOObar ./myscript.sh env -i bash # 清空所有继承来的环境变量进入一个干净环境env -i在复现纯净环境下的行为差异时特别有用。某些软件在环境变量被污染的情况下会出现诡异行为用干净环境一跑问题立刻暴露出来。6.3 变量扩展与默认值写法脚本里写环境变量还有一个高频需求给一个变量做兜底默认值。最常用的是${VAR:-默认值}export MY_ENV${MY_ENV:-/opt/default} echo $MY_ENV第一次执行时MY_ENV未定义输出/opt/default如果外部已经设置了MY_ENV则保留外部值。这类写法在做工具封装和 CI 参数注入时出现率很高比用if [ -z $VAR ]判断再赋值要简洁得多。还有一种用法是${VAR:默认值}区别在于前者只返回默认值、不修改变量本身后者会真的给变量赋上默认值。需要区分使用否则容易写出输出正确但变量没被修改的隐患代码。7. 收尾我踩过几次坑后形成的环境变量卫生习惯最后聊几句实操经验。跟环境变量打交道这几年我认为最有价值的一件事是把配置集中管理、每次修改都立即验证、并且清楚每个变量的来源。我的做法是这样用户级配置统一写在~/.bashrc.bash_profile只保留一行 source.bashrc不再堆其他内容。全局配置尽量用/etc/profile.d/下的独立文件而不是直接改/etc/profile。这样每个软件的初始化逻辑彼此隔离删除时也方便。每次改完配置立即执行source ~/.bashrc验证一遍验证用的是which java、echo $PATH这类能直接看到结果的手段而不是看起来没报错就完事。遇到命令找不到先查 PATH 顺序遇到软件版本不对先查 alternatives 和软链接遇到启动异常先跑bash -n和bash -x看语法和实际执行过程。另外一个小技巧在.bashrc里给 PATH 做追加时用 for 循环加数组而不是一行行复制粘贴这样配置增减软件时只需要动数组既好读也不会写乱。脚本里需要给某条命令临时注入变量时优先用VARvalue command前缀写法避免污染 shell 全局环境。这些习惯不一定适合所有人但至少能让我在半年后再看自己的配置时不用重新猜当初为什么要这么写。环境变量这套机制说到底不难难的是把它会加载哪个文件、谁会覆盖谁、改完怎么验证这三件事形成条件反射。把这三点记住运维和开发里的绝大多数环境变量问题都能迎刃而解。