Linux 环境变量这东西刚接触时觉得它就是个高级 PATH真正开始折腾 JDK、conda、systemd 服务之后才发现环境变量是所有诡异问题的源头。我见过不少人照着教程 export 完就以为配置好了结果新开一个终端又回到原点也见过线上服务明明手动执行一切正常一用 systemd 拉起来就报找不到命令。环境变量说到底就是一组键值对但它决定了 shell、编译器和各种服务怎么找到你的软件、怎么读取你的参数。这篇笔记是我这些年踩坑之后的个人整理会从环境变量本身的概念讲起把常用命令、配置文件加载顺序、JDK/conda/npm 这些真实配置案例以及排查思路都过一遍。适合刚接触 Linux 的开发者也适合被 command not found 折磨到怀疑人生的运维同学。1. 环境变量到底是什么先从概念理清楚1.1 从 PATH 说起为什么敲命令不用输入完整路径说到环境变量第一个必须聊的就是 PATH。PATH 这个变量保存了一堆目录路径路径之间用冒号分隔。当你敲ls的时候shell 并不会直接去/bin找而是把 PATH 里列出来的目录从左到右一个个翻直到找到同名的可执行文件然后执行。如果 PATH 里没有那个目录就会报command not found。这个过程可以用手机通讯录来类比。你平时打电话不会背号码只要搜索名字就能打通讯录里存了哪些号码你才能打通哪些人。PATH 就是 shell 的通讯录export PATH/your/bin:$PATH就是在往通讯录里加联系人。所以排查环境变量问题时第一反应应该是看 PATH 里有没有对应的目录而不是直接怀疑系统坏了。想要知道命令到底是从哪个目录来的可以用type -a ls或者which ls。这两个工具的区别在于type是 shell 内建命令能识别别名、函数和同名命令which则纯粹去 PATH 里搜。调试的时候我更喜欢用type -a因为它会把所有匹配项列出来方便看出是不是被别名或者旧版本抢先了。1.2 环境变量、shell 变量和作用域set 和 env 的区别很多新手分不清环境变量和普通 shell 变量其实规则很简单shell 变量是当前 shell 私有的环境变量则会被子进程继承。你可以先定义一个变量FOObar此时它只是 shell 变量用export FOObar之后才变成环境变量。判断的时候用env看环境变量用set看所有变量包括 shell 变量、函数和一堆 shell 内部变量。作用域也要分清楚。一个进程启动子进程时会把当前的环境变量原样拷贝过去。所以你在终端里export JAVA_HOME/usr/lib/jvm/java-17之后当前终端再启动的 Java 进程都能看到它但一旦关闭终端这个变量就没了因为它的生命周期只属于那个已经结束的 shell 进程。系统级环境变量写在/etc/profile、/etc/environment这类全局文件里用户级写在~/.bashrc、~/.profile里。生产环境我一般建议分两层全局通用的软件路径放系统级个人开发测试用的放用户级避免权限切来切去的时候遇到麻烦。2. 命令与配置文件最常用的几个核心操作2.1 查询与设置命令的参数速查真正干活的时候每天翻的也就那么几个命令。先列一张速查表后面再逐个解释。命令作用常用姿势env查看所有环境变量env直接看全部env | grep PATH过滤关键字echo查看某个变量的值echo $JAVA_HOMEexport设置或导出环境变量export MY_VARhellounset删除变量unset MY_VARset查看 shell 变量、函数和内部属性set | head -20printenv只打印环境变量比 env 干净printenv PATHsource重新加载配置文件source ~/.bashrcenv和printenv看起来很像但printenv是专门用来打印环境变量的不会像env那样可能还要兼顾其他输出。echo $VAR的写法也有一点坑如果你忘了写$只会输出一个字符串写了$但变量不存在会输出空行。调试的时候与其对着空行发呆不如加一句printenv VAR返回非零就是没定义。设置变量的时候export FOObar和FOObar; export FOO是等价的但我推荐前一种写法简单直接。特别要注意的是等号两边不能有空格export FOO bar会把当成变量名的一部分报语法错误。这个错误我在教程里见过不下十次算是新手高发地。2.2 配置文件的加载顺序login shell 与 non-login shell环境变量配置文件多是因为 Linux 区分登录 shell 和非登录 shell。登录 shell 指的是通过 tty、SSH 登录时启动的 shell非登录 shell 是你在已有终端里再开子 shell 的情况。登录 shell 会读取/etc/profile、~/.profile、~/.bash_profile不同发行版有差异非登录 shell 主要读~/.bashrc和/etc/bash.bashrc。在 Ubuntu/Debian 上比较常见的加载链是SSH 登录后bash 读/etc/profile然后/etc/profile会遍历/etc/profile.d/*.sh接着读~/.profile而~/.profile里通常又会去 source 一遍~/.bashrc。所以你在~/.bashrc写的变量SSH 进去之后其实也能看到。CentOS/RHEL 那边习惯更偏向~/.bash_profile它默认也会 source~/.bashrc。不同发行版细节差很多但结论一致不要在多个文件里写相同名字的变量否则你根本分不清谁覆盖了谁。我自己的配置策略很简单个人开发机统一写在~/.bashrc因为几乎所有交互式 shell 都会加载它而需要在登录时执行一次的初始化逻辑才放~/.profile。至于/etc/profile除非要全局影响所有用户否则坚决不碰。2.3 持久化配置的标准写法与 source 机制临时 export 只能活一个终端要永久生效就得写进配置文件。标准写法是export JAVA_HOME/usr/lib/jvm/java-17-openjdk-amd64 export PATH$JAVA_HOME/bin:$PATH关键点是第二行用了双引号并且把新目录加在了 PATH 前面。放在前面意味着优先被搜到如果你希望某个新版本软件优先于系统自带版本就要放到前面如果你只是补一个不常用的目录放后面也行。双引号不是可有可无的如果某个路径包含空格不加引号就会被拆成多个词导致 PATH 直接坏掉。改完配置之后需要source ~/.bashrc让它立刻生效或者新开一个终端。source的机制就是让当前 shell 去读配置文件并执行里面的命令相当于把文件内容一行行敲进当前 shell。所以如果文件里有语法错误source 的时候会直接报错但不会清掉当前已有的变量这点后面排查会用到。这里还要注意一个细节export PATH$JAVA_HOME/bin:$PATH里出现了$PATH这是在引用当前的值不是字符串本身。如果你写成export PATH/opt/jdk/bin:$PATH没问题但如果你写成export PATH/opt/jdk/bin:且忘了拼上$PATH那你的 PATH 就只剩一个目录了连ls都会找不到。后面我会专门讲这个紧急自救方法。3. 工具链场景从 JDK 到 conda环境变量配置实例3.1 JDK 环境变量JAVA_HOME 不只是拿来凑数配置 Java 的时候教程里一定会让你设JAVA_HOME、PATH、CLASSPATH。JAVA_HOME不是给 Java 自己用的而是给 Tomcat、Maven、Gradle 这类基于 Java 的软件用的它们需要靠这个变量定位 JDK 的安装目录。所以这个值一定不能随便写要指向 JDK 解压后的根目录里面能看到 bin、lib、include 这类子目录。这里用一个真实的 JDK 21 配置示例export JAVA_HOME/usr/local/jdk-21 export PATH$JAVA_HOME/bin:$PATH export CLASSPATH.:$JAVA_HOME/libCLASSPATH在 Java 9 之前非常重要因为当时的类加载默认会找它JDK 9 之后模块化改变了机制很多场景下不设置也能跑。我的建议是如果你只是本地编译运行可以不用设CLASSPATH避免因为漏掉当前目录.导致运行java Hello时找不到 class 文件。如果你确实遇到老项目需要再单独加.在最前面。安装 JDK 之后还有一个 Linux 自带的替代机制可以用update-alternatives --config java。这个工具会把系统里所有已注册的 JDK 管理起来把默认 java 指向其中一个。但要注意它管的是/usr/bin/java这个链接不一定会同步修改JAVA_HOME所以服务和构建工具依然认的是JAVA_HOME。如果你设置了错误的JAVA_HOME终端里java -version正常启动脚本却找不对版本这种情况很常见。3.2 Anaconda/conda 和系统 Python 的优先级博弈Anaconda 安装时会修改 shell 初始化脚本最常见的是在~/.bashrc末尾加上一段conda initialize然后执行source ~/.bashrc后会出现(base)前缀。这个前缀说明 conda 已经把base环境的 bin 目录塞到了 PATH 最前面于是你在终端里敲python跑的大概率是 conda 里的 Python而不是系统自带/usr/bin/python3。这套机制在深度教程里叫 shell hook它本质上也是环境变量操作。真要手动清理可以运行conda config --set auto_activate_base false这样登录后不会自动进 base但命令仍然能用需要时再conda activate base。优先级问题最容易出现在用 pip 和 conda 混合装包的时候。如果你在 base 环境里pip install flask然后又conda install flask两个包可能在同一个环境目录下互相覆盖。排查时先which python再看输出路径里有没有 conda 的痕迹比如/home/user/anaconda3/bin/python。如果系统里只有一个 Python 版本反而不用纠结但如果项目要求必须用/usr/bin/python3在运行脚本之前显式/usr/bin/python3 script.py会更稳妥。3.3 npm、Git、FFmpeg、Docker 的 PATH 补充与校验Node.js 和 npm 的安装方式决定了环境变量要不要改。如果从 nodejs.org 下载的是 .tar.xz 包并解压到/opt/nodejs那 /opt/nodejs/bin 肯定不会自动进 PATH需要手动加export PATH/opt/nodejs/bin:$PATH如果直接用的发行版仓库里的 Node多半是老版本一般不需要手动配。npm 全局安装包的可执行文件会放在npm prefix指定的目录可以用npm config get prefix查看。如果这个目录不在 PATH 里npm i -g xxx装完依然找不到命令。我一般会把 npm 的前缀设置成/usr/local下某个固定目录然后把路径加进 PATH。Git 本身通常不需要配 PATH因为/usr/bin/git已经在系统路径里。但有些从源码编译安装的 Git 放在/usr/local/git/bin就需要在配置里加一句。FFmpeg 同理无论是 apt 安装还是源码编译只要二进制所在的目录没进 PATH都会出现命令找不到。Docker 一般安装后会自动放到/usr/bin/docker但如果你用 Docker Desktop Linux 版本可执行文件可能放在~/.docker/bin也要确认。配置完之后最有效的验证方式是command -v node。command -v比which更规范它会告诉你 shell 实际会执行哪个路径而且对于 shell 内建命令也能正确识别。如果command -v输出的是/opt/nodejs/bin/node说明 PATH 生效了如果是空说明目录没匹配上。4. systemd、Jenkins 与服务场景环境变量在服务里经常翻车4.1 systemd 的 EnvironmentFile 与 Environment 指令手动在终端跑程序一切正常放进 systemd 服务就找不到命令这是非常典型的服务环境变量问题。systemd 启动的服务环境极其精简不会读取你的~/.bashrc、/etc/profile也不会继承你登录 shell 里的环境。所以在 service unit 里必须显式指定环境变量。最常用的两种方式[Service] EnvironmentJAVA_HOME/usr/local/jdk-21 EnvironmentFile/etc/myapp.env ExecStart/usr/local/jdk-21/bin/java -jar /opt/myapp/app.jarEnvironment适合少量变量EnvironmentFile适合从集中配置里加载。从文件加载时格式必须是每行一行KEYVALUE不能有export前缀不能有引号包裹整个文件内容空行和#注释会被忽略。需要注意的是systemd 官方的EnvironmentFile解析规则比较严格值里的反斜杠不会被转义$不会被展开双引号也会被当成普通字符。如果配置文件里有特殊字符建议用单引号手动测试。修改 unit 之后记得systemctl daemon-reload然后重启服务。还有一个排查技巧用systemctl show 服务名 -p Environment看看 systemd 最终确定的环境变量列表再对比 ExecStart 命令实际用到的变量基本就能定位问题。对了生产环境不建议在 EnvironmentFile 里放明文密钥这个文件如果权限是 644同主机用户就能读至少改成 600 并确认归属用户。4.2 Jenkins 构建里的环境变量来源Jenkins 的环境变量比 systemd 复杂一点因为至少有三个来源master 节点系统环境变量、Jenkins 全局配置里的环境变量、当前构建 Job 里的参数。执行 shell 构建步骤时脚本看到的环境变量是这三者叠加之后的结果和你在服务器 SSH 终端里看到的不一样因为 Jenkins 自身的服务也可能由 systemd 启动因此同样不继承你手动配置的~/.bashrc变量。看一个常用排查姿势在 Jenkins 的构建步骤里加一句env | sort把输出存到日志里再对比printenv在服务器终端下的输出。差在哪基本就是环境变量没有传进来的问题。如果需要在所有 Job 里共用某个路径最稳妥的是在 Jenkins 系统配置里通过“全局属性”添加键值对或者在服务启动脚本里 source 一个环境文件保证不管谁启动都能读。还有个小坑有些构建脚本用了#!/bin/bash但 Jenkins 默认执行 shell 的方式可能不是登录 shell所以不会读取/etc/profile。你可以在脚本开头显式source /etc/profile source ~/.bashrc但也别乱写因为如果执行环境根本没有那个文件脚本反而会卡在 source 这一步。用if [ -f /etc/profile ]; then . /etc/profile; fi比较安全。4.3 远程 SSH 和容器环境差异SSH 登录服务器时获得的是一个登录 shell理论上会加载/etc/profile和~/.profile。但如果你通过ssh host docker exec ...这种方式执行命令有些环境就不一定走完整的登录流程了。尤其在使用脚本进行远程命令调用时建议先用ssh host env看看到底传了哪些变量不要假设~/.bashrc一定生效。容器里的环境变量是另一个大坑。docker run的-e参数只影响容器内 PID 1 进程entrypoint 和 shell 脚本是否保留变量取决于脚本自己。如果你在 Dockerfile 里用ENV设置变量镜像构建时写死运行时不改。如果容器里的应用找不到某个配置优先docker exec 容器名 env查看当前环境别一上来就怀疑程序本身。容器和宿主的 PATH 差异也经常让人疑惑。宿主机装在/opt/foo/bin的命令容器里不一定有反过来容器里python可能是软链宿主上是另一个版本。所以跨环境迁移脚本尽量在脚本内用绝对路径或者先把环境变量统一导出成文件再传给容器。5. 常见问题排查与避坑实录5.1 配置不生效先搞清楚你启动的是 login shell 还是 non-login shell配置环境变量之后经常遇到“我已经 source 了怎么新终端还是看不到”。第一个要确认的是你改的文件到底对不对。如果你在~/.bash_profile里加了变量然后开图形终端这种通常是 non-login shell只读~/.bashrc自然看不到。反过来也一样。进入排查前先跑bash -l -c echo test模拟登录 shell或者直接 SSH 到自己机器上看效果。如果你发现登录 shell 和非登录 shell 加载的文件不一样我的办法是只在~/.bashrc里写变量然后确认~/.profile或者~/.bash_profile里有 source~/.bashrc的语句。绝大多数发行版默认都有但对方给了精简过的主目录可能会缺。还有一个容易忽略的点某些系统管理工具会使用/etc/environment这文件不经过 shell 解析只支持简单的KEYVALUE行不能写$VAR和命令替换。如果你把export PATH$PATH:/xxx写进这个文件重启后系统登录环境会变得很奇怪。判断依据很简单服务管理器如 systemd user session会读取这个文件但 shell 不一定会把它当成命令执行。5.2 sudo 后环境变量丢失env_reset 与 sudo -E很多人在脚本里写了sudo javac结果提示找不到 javac明明 PATH 里已经有 JDK。原因在于 sudo 默认会重置环境变量这个策略由/etc/sudoers里的env_reset控制。也就是说你当前 shell 的 PATH 不会自动传给 sudo 启动的命令sudo 会用一个安全默认的 PATH。临时解决方案是sudo -E表示保留当前用户的环境变量。但有两点要注意-E只在你当前用户的权限允许范围内生效如果你用sudo su依然可能会重新加载 root 的环境配置文件。更稳妥的做法是直接给 sudo 配置指定允许保留的变量在/etc/sudoers里加一行Defaults env_keep JAVA_HOME修改 sudoers 一定用visudo因为语法错了会导致 sudo 不可用。这里多提醒一句不要因为图省事就把整个 PATH 都无条件 env_keep安全策略上越保守越好。如果只是临时跑一次命令优先sudo -E或者干脆/usr/bin/sudo /usr/local/jdk-21/bin/java。如果你维护的是一批服务器最好在一开始就统一约定 PATH 的默认内容把常用目录放进/etc/profile.d/下的一个.sh文件里再为 sudo 单独配一个覆盖。这样即使登录用户没配置root 执行时的路径也是显而易见的不会每个排障现场都要猜。5.3 PATH 配错后 command not found 的应急自救最吓人的经验之一是在配置文件里手滑写了一句export PATH/only/one/dir然后source完发现ls、cat、cd甚至sudo全都不见了。别慌因为有很多命令是 shell 内建功能比如cd不会受影响但外部命令会全部失效。这个问题的自救思路是先用绝对路径调用命令恢复 PATH。比如/bin/echo $PATH /usr/bin/export PATH/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin第一行只是确认当前 PATH第二行里/usr/bin/export其实不存在因为export是 shell 内建不需要写成绝对路径直接export PATH/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin就行。恢复后马上检查配置文件把错误的行修掉再source。关键是不用重开终端也不用重启。如果你的 shell 没有 sudo且找不到编辑器的绝对路径可以用/bin/vi或/usr/bin/nano它们通常在标准路径里。对这些应急命令熟不熟直接决定能多快恢复。我的建议是第一次配环境变量的朋友提前把/usr/bin和/bin的常用命令记一下至少知道ls在/bin/ls或/usr/bin/lscp在/usr/bin/cp。5.4 环境变量里的引号、空格和换行坑最后一块是环境变量本身的值格式。很多软件安装目录带空格比如 Windows 下常见Linux 很少但自定义安装到/opt/my tools/bin的话加载时就特别容易翻车。正确写法一定是export MY_TOOLS/opt/my tools export PATH$MY_TOOLS/bin:$PATH关键是双引号包住整个路径。如果你写成export PATH/opt/my tools/bin:$PATHshell 会把/opt/my和tools/bin:$PATH当成两个词变量直接坏掉。还有一种情况是配置文件里有 Windows 风格的换行符\r看起来正常source 的时候会报$\r: command not found。解决办法是sed -i s/\r$// ~/.bashrc以后不要在 Windows 下写配置再传到 Linux。排查环境变量还能用bash -x跟踪 source 过程比如bash -x -l -c exit会把登录时执行的所有命令打出来看哪里报错。另外一个实用技巧是配置前先备份改完 source 前先跑bash -n ~/.bashrc检查语法。这些步骤加起来不到十秒能省下后面一小时的排障时间。我个人在实际操作里最大的体会是环境变量问题的尽头永远是配置文件加载顺序和进程继承规则。遇到莫名其妙的丢失第一反应应该是env | sort看看当前进程到底有什么而不是反复去改 export。先把概念框架搭起来再去处理具体工具链绝大多数坑都能在十分钟内定位。最后分享一个小技巧所有新增的环境变量我习惯在同一个文件里集中维护并写成带注释的区块避免过一个月回来看完全不知道哪个变量是干什么用的。环境变量本身不复杂复杂的是你让它活在什么样的 shell 和服务场景里。