3. 常见环境变量冲突场景——多版本工具共存的噩梦
说实话，环境变量冲突这玩意儿，我见过太多人栽跟头了。尤其是咱们开发机上一堆工具混着用的时候——JDK 好几个版本、Python 虚拟环境切来切去、Node.js 版本管理工具还来凑热闹。PATH 变量一旦乱掉，你连最基本的命令都跑不了。
这一节，我就把最常见的三种冲突场景掰开揉碎了讲。你想想看，搞清楚了这些，以后排查问题至少能省一半时间。
3.1 多个 JDK 版本共存——谁才是默认的 java？
我刚开始做 Java 开发那会儿，电脑上装了 JDK 8 和 JDK 11。有一天跑一个老项目，死活编译不过去。查了半天，发现 java -version 显示的是 11，但项目需要 8。嗯，这就是典型的 JDK 版本冲突。
为什么会这样？说白了，就是 PATH 变量里哪个 JDK 的 bin 目录排在前面，系统就用哪个。
核心问题：多个 JDK 的 bin 目录同时出现在 PATH 中，顺序决定默认版本。
我建议你养成一个习惯：用 which java 和 java -version 两个命令一起确认当前生效的 JDK。光看版本号不够，还得看路径。
# 查看当前 java 路径
$ which java
/usr/bin/java
# 查看 PATH 中的 JDK 顺序
$ echo $PATH | tr ':' '\n' | grep -i jdk
/usr/lib/jvm/jdk-11/bin
/usr/lib/jvm/jdk-8/bin
# 查看 java 版本
$ java -version
openjdk version "11.0.18" 2023-01-17 LTS
你看，虽然 JDK 8 也在 PATH 里，但 JDK 11 排前面，所以默认用的是 11。我在项目中遇到过好几次，开发环境配好了，部署到服务器上就炸了——因为服务器上 JDK 顺序不一样。
我的习惯：用 update-alternatives（Linux）或 jenv（macOS）来管理 JDK 版本，别手动改 PATH。手动改容易改乱，而且不同终端配置还不一样。
3.2 Python 虚拟环境与系统 Python 冲突——pip 装到哪去了？
Python 的虚拟环境冲突，我估计每个 Python 开发者都踩过坑。你激活了虚拟环境，以为所有包都装在里面了，结果一查，pip 装到了系统目录。更离谱的是，有时候 python 指向虚拟环境，但 pip 还指向系统路径。
为什么会这样？因为虚拟环境激活脚本只修改了 PATH 的前半部分，但如果你之前手动设置了 PYTHONPATH 或 PIP_REQUIRE_VIRTUALENV，那就乱套了。
我曾经踩过的坑：在虚拟环境里执行 pip install，结果包装到了系统 Python 的 site-packages 里。后来发现是因为我用了 sudo pip install，sudo 会重置 PATH，虚拟环境就失效了。
我建议你每次激活虚拟环境后，先确认一下路径：
# 激活虚拟环境
$ source venv/bin/activate
# 确认 python 和 pip 路径
(venv) $ which python
/home/user/project/venv/bin/python
(venv) $ which pip
/home/user/project/venv/bin/pip
# 检查 PYTHONPATH 是否被污染
(venv) $ echo $PYTHONPATH
# 如果输出为空，说明没被污染，这是最好的情况
还有一个常见的坑：你在虚拟环境里用 !python（Jupyter Notebook 里的魔法命令），它可能不认虚拟环境。我建议在 Jupyter 里专门配置内核，别依赖 PATH。
| 场景 | 问题 | 排查方法 |
|---|---|---|
| 虚拟环境激活后 pip 装到系统 | 使用了 sudo 或 PATH 顺序错误 | which pip 确认路径 |
| python 和 pip 版本不一致 | 虚拟环境创建时指定了不同 Python 版本 | python --version 和 pip --version 对比 |
| PYTHONPATH 覆盖了虚拟环境 | 在 .bashrc 或 .zshrc 中设置了 PYTHONPATH | echo $PYTHONPATH 检查 |
3.3 Node.js 版本管理工具导致的 PATH 混乱
Node.js 这块更热闹。nvm、n、fnm、volta……版本管理工具一大堆。每个工具都有自己的方式修改 PATH。你装了两个工具，它们互相打架，最后 node -v 显示的版本你都不知道是谁决定的。
我记得有一次帮同事排查问题，他电脑上装了 nvm 和 fnm。nvm 在 .bashrc 里加了一段脚本，fnm 在 .zshrc 里也加了一段。两个工具都在 PATH 前面插自己的目录，结果 node 指向了 nvm 的版本，但 npm 指向了 fnm 的版本。你说乱不乱？
核心原则：同一时间只用一个 Node.js 版本管理工具。混用必出问题。
我建议你选一个工具用到底。我个人习惯用 nvm，因为它生态最成熟。但不管你选哪个，都要确保其他工具的配置被清理干净。
# 检查当前 node 路径
$ which node
/Users/user/.nvm/versions/node/v18.16.0/bin/node
# 检查 PATH 中所有 node 相关路径
$ echo $PATH | tr ':' '\n' | grep -i node
/Users/user/.nvm/versions/node/v18.16.0/bin
/usr/local/bin/node
# 如果发现多个路径，说明有冲突
还有一个容易被忽略的点：全局安装的 npm 包。你用 nvm 切了 Node 版本，但全局包还在老版本的目录里。这时候运行全局命令，可能报错或调用错误的模块。
我的做法：每次切换 Node 版本后，用 npm ls -g --depth=0 检查全局包是否还在。如果不在，重新安装常用的全局工具，比如 npm install -g yarn、npm install -g typescript。
3.4 一张图看懂环境变量冲突的核心逻辑
说了这么多，我画了一张图帮你理清思路。这张图展示了 PATH 变量如何被多个工具修改，以及最终哪个版本生效。
这张图你看懂了吗？从上往下看，系统初始 PATH 被三个工具分别修改，最终在冲突区域里，谁排在 PATH 前面谁就生效。说白了，这就是一个「先到先得」的游戏。
3.5 通用排查方法论
不管你是遇到 JDK 冲突、Python 冲突还是 Node.js 冲突，排查思路其实是一样的。我总结了一个三步法：
- 确认当前命令路径：用
which或type命令，看系统到底调用了哪个可执行文件。 - 检查 PATH 顺序：用
echo $PATH查看所有路径，按冒号分隔，从左到右依次检查。 - 定位配置来源：检查 .bashrc、.zshrc、.profile 等配置文件，看 PATH 是在哪里被修改的。
我曾经犯过的错：有一次排查了半天，发现 PATH 在 .bashrc 和 .bash_profile 里各改了一次，而且顺序相反。两个文件都会被执行，后执行的覆盖了先执行的。所以一定要搞清楚你的 shell 加载了哪些配置文件。
嗯，这一节的内容就到这里。你把这些场景记住了，以后遇到环境变量冲突，至少知道从哪下手。排查问题最怕的就是没头绪，有了这三类场景的认知，你就能快速定位问题根源了。