每个敲过命令行的人，几乎都被这两句话拦过：类 Unix 系统上的 command not found，Windows 上的 'xxx' 不是内部或外部命令，也不是可运行的程序或批处理文件。报错本身简单，背后却牵出同一套机制——环境变量（environment variable），以及其中最关键的一个成员 PATH。装完一个工具却在终端里"找不到命令"、不同终端里行为不一致、版本切换工具到底改了什么、配置改了却不生效……这些问题十有八九都和它们有关。这篇文章从原理讲到实战，把环境变量与 PATH 的运作机制、查看与设置方式、以及多版本管理背后的套路一次讲清。

前言：为什么需要环境变量

程序运行时需要大量配置信息：临时目录在哪、用什么语言区域、代理地址是什么、可执行文件去哪找。这些配置如果全写死在代码里，换一台机器就得重新编译；如果每个程序自己搞一套配置文件，又重复造轮子。环境变量就是操作系统提供的一套进程级、可继承的键值对配置机制：系统给每个进程维护一份环境变量表，程序运行时直接读取，无需自己解析配置文件。

它和 shell 里用 VAR=value 定义的普通变量最大的区别在于：环境变量会被子进程继承。当你在 shell 里 export 一个变量，再用这个 shell 启动其他程序时，那个程序能直接读到这个值；而普通 shell 变量只存在于当前 shell 内部，不会传给子进程。这个"继承"特性是理解后面所有行为的关键。

核心概念

环境变量：进程级、可继承的键值对

操作系统给每个进程都维护一张环境变量表，里面是一组 KEY=VALUE 的键值对。进程启动时，这张表由父进程拷贝而来（fork 时继承），之后子进程对它的修改只影响自己，不会回传给父进程。

这张图说明了一件常被忽略的事：子进程对环境变量的修改，父进程看不到。 这也是为什么你在脚本里 export PATH=... 改了 PATH，脚本结束后当前 shell 的 PATH 没变——脚本是在子 shell 里跑的。

环境变量的常见用途：

用途	典型变量	说明
临时目录	TEMP / TMPDIR	程序写临时文件的目录
语言区域	LANG / LC_ALL	决定字符集、日期格式等
代理	HTTP_PROXY / HTTPS_PROXY	告诉程序走哪个代理
用户主目录	HOME（类 Unix）/ USERPROFILE（Win）	当前用户主目录
命令查找路径	PATH	shell 在哪里找可执行文件

最后那个 PATH，是接下来要重点讲的对象。

PATH：决定"命令去哪找"的特殊变量

当你在终端输入 node 并回车，shell 怎么知道去哪里找 node 这个程序？它不会全盘扫描硬盘，而是查 PATH 这个环境变量。PATH 是一组用分隔符隔开的目录列表，shell 会按从左到右的顺序，依次到这些目录里找有没有同名的可执行文件，找到第一个就用。

• 类 Unix 用冒号 : 分隔：/usr/local/bin:/usr/bin:/bin
• Windows 用分号 ; 分隔：C:\Program Files\nodejs;C:\Windows\system32

这里有两个关键点会反复在实战里出现：顺序敏感（前面目录里的同名程序会"遮蔽"后面的），以及找不到就报 command not found（即使程序确实装在机器上，只要它所在的目录不在 PATH 里，shell 就当它不存在）。

实战演练

场景 1：查看与临时设置环境变量

先学会"看"。不同平台查看环境变量的方式：

# Linux/macOS：列出全部环境变量
env
# 或
printenv

# 查看某个变量
echo $PATH
printenv PATH

# Windows PowerShell：列出全部
Get-ChildItem Env:

# 查看某个变量
$env:PATH

临时设置一个环境变量，只对当前 shell 会话有效，关掉终端就没了：

# Linux/macOS：用 export 才会传给子进程
export MY_VAR="hello"
echo $MY_VAR   # hello

# 只赋值不 export，子进程看不到
OTHER_VAR="world"

# Windows PowerShell
$env:MY_VAR = "hello"
$env:MY_VAR   # hello

注意类 Unix 上 export 与不 export 的区别：只有 export 出去的才是环境变量，才会被子进程继承；不 export 的只是 shell 局部变量。

场景 2：持久化设置环境变量

临时设置只管当前会话。要让配置在每次开终端时都生效，得写到持久化的地方。

Linux/macOS：写到 shell 的启动脚本里。不同 shell 读不同的文件：

Shell	交互式登录 shell	交互式非登录 shell
bash	~/.bash_profile（或 ~/.profile）	~/.bashrc
zsh（macOS 默认）	~/.zprofile	~/.zshrc

实战中最省心的做法：把配置写到 ~/.bashrc 或 ~/.zshrc，然后在 ~/.bash_profile / ~/.zprofile 里 source 它，保证两种场景都生效。

# 在 ~/.zshrc 末尾追加
export PATH="$HOME/.local/bin:$PATH"
export HTTP_PROXY="http://127.0.0.1:7890"

改完之后不会立即生效，要么重开终端，要么手动重新加载：

source ~/.zshrc   # 或 . ~/.zshrc

这是新手最常踩的坑之一：改了配置文件却忘了 source，以为没生效。

Windows：环境变量存在注册表里，分用户级和系统级。设置方式有三种，按推荐程度排序：

# 方式 1（推荐）：用 .NET API，最灵活，可指定作用域
# 用户级（推荐，不需要管理员）
[Environment]::SetEnvironmentVariable("MY_VAR", "hello", "User")
# 系统级（需要管理员，对所有用户生效）
[Environment]::SetEnvironmentVariable("MY_VAR", "hello", "Machine")

# 方式 2：setx 命令，简单但有长度限制（1024 字符）
setx MY_VAR "hello"            # 用户级
setx MY_VAR "hello" /M         # 系统级，需管理员

# 方式 3：GUI 图形界面
# Win+R → sysdm.cpl → 高级 → 环境变量

重要提醒：setx 和 SetEnvironmentVariable 写的都是持久化的注册表值，但它们不会修改当前 PowerShell 会话的 $env:PATH。当前会话要立即生效，得自己再赋一次值。

[Environment]::SetEnvironmentVariable("MY_VAR", "hello", "User")
$env:MY_VAR = "hello"   # 当前会话立即生效

这一点和 Linux 上"改完配置文件要 source"是同一类问题：持久化的配置和当前会话的内存值是两套，需要手动同步。

场景 3：PATH 查找机制与"命令找不到"排查

现在回到开头那个 command not found。装完一个工具却在终端里找不到，按这套流程排查：

对应的排查命令：

# Linux/macOS：看 shell 实际用的是哪个
which node        # 显示 PATH 里第一个匹配的路径
type node         # 更全面，连 alias/function 都显示

# Windows PowerShell
Get-Command node          # 等价于 which
where.exe node            # 传统命令，列出所有匹配

几个典型原因：

• 没加 PATH：程序装在 ~/apps/foo/bin，但这个目录不在 PATH 里。解决：把它加进去。
• PATH 顺序遮蔽：PATH 里前面的目录有个旧版 node，新装的在后面，永远先找到旧的。解决：把新目录放到 PATH 前面，如 export PATH="/new/path:$PATH"。
• 没执行权限（类 Unix）：文件存在但没 x 权限。chmod +x foo 修复。
• 扩展名问题（Windows）：Windows 上 PATHEXT 变量决定哪些扩展名可以省略后缀直接敲。默认包含 .COM;.EXE;.BAT;.CMD 等。如果你装的是 .ps1 脚本但没在 PATHEXT 里，敲名字就找不到。
• 改了配置没重开终端：前面说过，持久化值不会自动同步到当前会话。

场景 4：用 PATH 管理多版本工具

理解了 PATH，就能看懂一票版本管理工具在干什么。nvm、pyenv、rbenv、scoop、fnm……它们的套路几乎一致：在 PATH 最前面插一个"调度目录"，切换版本时只改这个目录的指向。

以 nvm 为例：

~/.nvm/versions/node/
├── v18.20.0/bin/node
├── v20.10.0/bin/node
└── v22.3.0/bin/node

当前 node  ──symlink/junction──>  v20.10.0/bin/node

nvm 会把一个类似 ~/.nvm/current/bin 的目录放到 PATH 最前面，nvm use 20 时，它只是把这个目录里的符号链接（或 junction）重新指向 v20.10.0/bin。shell 查 node 时永远先查到这个调度目录里的链接，于是版本切换瞬间完成，无需改 PATH 本身。

这套机制的好处是：PATH 只配一次，版本切换靠改链接，互不干扰。 Windows 上 scoop 也是同一个思路——它用 junction 指向 current 版本，PATH 里永远写 ...\scoop\shims。前一篇《删不掉的 junction》里那个悬空 junction，正是 scoop 用这套机制时留下的副作用：卸载删了真实目标，junction 自己却没被清掉。

理解了"版本管理 = 操作 PATH/链接"，再遇到版本切换工具的奇怪行为（切了版本不生效、卸载残留删不掉），就有了排查方向。

最佳实践与常见陷阱

PATH 的顺序就是优先级。 把你想优先用的版本所在目录放在 PATH 前面。很多工具的安装脚本会把自己的目录 prepend 到 PATH，就是为了让自己的命令"盖过"系统自带的。

不要往 PATH 里塞太多目录。 PATH 越长，每次命令查找要扫的目录越多。更重要的是，目录越多越容易出现同名遮蔽——你以为执行的是 A，其实被前面的 B 顶替了。定期用 echo $PATH 审一遍，清掉不再用的。

区分临时设置与持久化设置。 临时 export / $env:X= 只管当前会话，适合一次性测试；要长期生效必须写配置文件或注册表。改完持久化配置后记得 reload（类 Unix 上 source，Windows 上重开终端或手动同步 $env）。

Windows 上注意用户级与系统级的区别。 用户级变量只对当前用户生效，不需要管理员，推荐优先用；系统级对所有用户生效，需要管理员。两者都会被合并到进程的环境里，同名时用户级会覆盖系统级。

大小写的平台差异。 类 Unix 上环境变量名区分大小写，PATH 和 Path 是两个变量；Windows 上不区分大小写，PATH、Path、path 是同一个。跨平台脚本里统一用大写最安全。

别把密钥硬编码进配置文件再提交到 git。 环境变量常用来存 API key、token，但 .bashrc、.zshrc 这类文件很容易被一起 commit。敏感信息单独放一个不纳入版本控制的文件（如 ~/.secrets），再在启动脚本里 source 它。

改完 .bashrc/.zshrc 要 source。 这条单独提出来，因为它踩中率太高：改了文件、没 source、以为没生效、又改一遍——结果文件里同一行被加了好几次，PATH 越来越长。

总结

• 环境变量是操作系统给每个进程维护的键值对配置，会被子进程继承，这是它和普通 shell 变量的本质区别。
• PATH 是其中最特殊的一个，决定 shell 在哪些目录、按什么顺序找可执行文件；顺序敏感、找不到就报 command not found。
• 持久化设置：类 Unix 写 ~/.zshrc/~/.bashrc 并 source，Windows 用 [Environment]::SetEnvironmentVariable 或 setx，注意持久化值与当前会话值是两套，要手动同步。
• "命令找不到"按"装了没 → 在 PATH 里没 → 顺序对没 → 权限/扩展名没 → 重开终端没"五步排查。
• 多版本管理工具（nvm/pyenv/scoop）的套路本质相同：PATH 里放一个调度目录，切版本靠改链接，不动 PATH。

搞懂这套机制，命令行里九成的"找不到命令"“版本不对”"配置不生效"都能自己定位。