1. 环境变量是什么？为什么它会引发冲突？
说实话，我做了十几年运维和开发，遇到最多的诡异问题，十有八九都跟环境变量有关。明明代码在本地跑得好好的，部署到服务器就报错；明明刚配好的 Java 环境，换个终端窗口又找不到了。这些坑，我几乎都踩过一遍。
环境变量到底是什么？说白了，它就是操作系统给进程准备的一个「全局配置表」。每个进程启动时，系统都会塞给它一张键值对列表，告诉它去哪找命令、去哪找库、去哪找配置。这张表，就是环境变量。
1.1 三大核心变量：PATH、JAVA_HOME、PYTHONPATH
我习惯把环境变量分成三类：路径定位型、工具配置型、语言运行时型。咱们从最常见的三个入手。
| 变量名 | 类型 | 作用 | 冲突后果 |
|---|---|---|---|
PATH |
路径定位型 | 告诉 shell 去哪里找可执行文件 | 命令找不到、版本错乱 |
JAVA_HOME |
工具配置型 | 指定 JDK 安装根目录 | Maven/Gradle 编译失败 |
PYTHONPATH |
语言运行时型 | 指定 Python 模块搜索路径 | Import 报错、模块版本冲突 |
PATH 是最容易出问题的。我记得有一次线上排查，同事说 curl 命令突然不好使了。我一看，PATH 里居然有两个 curl 路径，一个在 /usr/bin，一个在 /usr/local/bin，而且顺序还反了。系统默认取第一个，结果调了个旧版本，TLS 握手一直失败。
JAVA_HOME 的坑更隐蔽。很多工具不直接读 PATH 里的 java，而是读 JAVA_HOME。你装了 JDK 11 和 JDK 8，PATH 指向了 11，但 JAVA_HOME 还指着 8。Maven 一编译，直接报 Unsupported class file major version。嗯，这种问题我至少帮人排查过十几次。
PYTHONPATH 嘛，Python 开发者应该深有体会。你装了一个包，但 Python 还是从另一个路径导入旧版本。为什么？因为 PYTHONPATH 里有个路径优先级更高，把 site-packages 给覆盖了。
1.2 环境变量的加载机制
环境变量不是凭空出现的。它有一套完整的加载链。我画了一张图，你看完就明白了。
加载顺序是这样的：系统级配置最先加载，然后是用户级，最后是 Shell 会话级。后加载的会覆盖先加载的。你想想看，如果 /etc/environment 里配了 JAVA_HOME=/usr/lib/jvm/java-8，~/.bashrc 里又配了 JAVA_HOME=/usr/lib/jvm/java-11，那最终生效的是哪个？没错，是 ~/.bashrc 里的那个。
echo $变量名 确认当前值，再用 which 命令 确认实际调用的路径。这两个命令能帮你省掉 80% 的排查时间。
1.3 冲突的根源
环境变量冲突，归根结底就三个原因。
- 覆盖冲突：多个配置文件定义了同一个变量，后加载的覆盖了前一个。你以为是 A 版本，实际跑的是 B 版本。
- 顺序冲突：PATH 里多个路径包含同名命令，系统只认第一个。我遇到过有人把
/usr/local/bin放在/usr/bin后面，结果新装的工具永远调不到。 - 继承冲突：父进程的环境变量被子进程继承，但子进程改了之后不影响父进程。这导致同一个用户在不同终端里看到的环境不一样。
/etc/profile.d 里配好了 JAVA_HOME，但 Tomcat 启动脚本里又手动 export 了一个不同的版本。结果 Tomcat 进程用的是脚本里的版本，而系统其他工具用的是 profile 里的版本。排查了整整一个下午，最后发现是启动脚本第 37 行有个 export 覆盖了全局配置。从那以后，我养成了一个习惯：所有环境变量配置统一放在 /etc/environment 或 ~/.bashrc，绝不在启动脚本里临时 export 关键变量。
1.4 如何快速查看当前环境变量
排查冲突之前，你得先知道当前环境里到底有什么。这几个命令我几乎天天用。
# 查看所有环境变量
env
# 查看单个变量
echo $PATH
echo $JAVA_HOME
echo $PYTHONPATH
# 查看命令实际路径
which java
which python
which mvn
# 查看进程的环境变量（PID 替换为实际进程号）
cat /proc/<PID>/environ | tr '\0' '\n'最后一个命令特别实用。有时候你在终端里看到的环境变量，跟实际进程里跑的不一样。为什么？因为进程可能是由 systemd 或别的守护进程启动的，它继承的是父进程的环境，不是你当前 Shell 的环境。
1.5 一个典型的冲突场景
我拿 Python 开发环境举个例子。你装了 Python 3.9 和 Python 3.11，PATH 里两个路径都有。你运行 python，系统找到了 3.9。但你的项目需要 3.11 的特性。你改了 PATH，把 3.11 的路径放前面。好，现在 python 指向 3.11 了。但你的 IDE 还是用 3.9，因为 IDE 读的是 PYTHONPATH 或者它自己的配置。
更麻烦的是，你装了 pip install requests，它装到了 3.9 的 site-packages 里。但你用 3.11 跑代码，import requests 报错。为什么？因为两个 Python 版本各自维护自己的包目录，互不干扰。你以为装上了，其实装错了地方。