环境变量是什么

环境变量（Environment Variable）：操作系统提供给进程的键值对。进程启动时继承父进程的整个环境，可用于配置程序行为、传递路径信息等。常见如 HOME、USER、SHELL、LANG。

PATH：最核心的环境变量，告诉 Shell 在哪些目录中按顺序搜索可执行文件。敲一条命令时，Shell 挨个扫 PATH 里的目录——先找到的就执行，后面的不再查。

动态库搜索路径：程序运行时查找共享库（Linux .so、macOS .dylib、Windows .dll）的机制。逻辑与 PATH 类似但机制因平台差异极大，是最容易踩跨平台坑的领域。

我什么时候会用到它

抛开应用程序主动用它传配置不谈，最常用的场景就是手动安装命令行工具。处于某些原因我们不想用包管理器或安装器安装程序时（它们通常会帮你配置好环境变量）而是直接下载一个压缩包的可执行文件使用时，我们要告诉 Shell 在哪里找到我们下载的可执行文件，即配置环境。通常情况下，只需要将可执行文件所在的目录添加到 PATH 环境变量里即可。那么，怎么添加？——

怎么读

环境变量的读取范围分四层，搞不清这个是"设了但不生效"的第一大原因：

同名变量在多层设置时，层级越窄优先级越高： 进程级 > Shell级 > 用户级 > 系统级）

这里的行为，与其说是平台特定，不如说是 Shell 特定：比如，如果你在 Windows 上用 Bash，那其实更应该参考 Linux 的设置。

为什么写文件可以修改环境变量？这是 Shell 的设计机制：Shell 启动时会按一定规则运行特定的初始化脚本，而作为所有命令的入口，所有的 Shell 都设置了的环境，相当于就是整个用户/系统的环境。

特例：

• Linux /etc/environment 是用户登录时由 PAM 读取的，格式为 KEY=VALUE
• macOS /etc/paths 只管 $PATH，每行一个路径，不是 KEY=VALUE 格式；/etc/paths.d/* 同理（每个文件一行一个路径）

Shell 的 Login / Non-login——Linux/macOS 最大的坑

Shell 启动方式决定它读取哪些配置文件，这直接决定你的环境变量在哪个文件里写才能生效：

bash 读取顺序

bash 的 Login Shell 优先级列表 ~/.bash_profile > ~/.bash_login > ~/.profile 诞生于 Unix 历史的“兼容期”，它是为了解决多流派 Shell 用户的迁移问题，而非让你把三个文件都用上。

1. ~/.profile 是 Bourne Shell (sh) 的老祖宗标准： 在当年，所有 Unix 系统的默认 Shell 都是 sh，大家都把环境变量写在 ~/.profile 里。直到今天，如果你用的是 Ubuntu，它的底层系统默认 Shell 是 dash，dash 启动时依然只认 ~/.profile。
2. ~/.bash_login 是对 C Shell (csh) 的妥协：当年有一大批写 ~/.login 的 csh 用户转投 Bash，为了照顾他们的习惯，Bash 加了这个支持。
3. ~/.bash_profile 是 Bash 的“亲儿子”：Bash 诞生增加了很多 sh 不支持的高级语法（比如数组、特殊的字符串处理）。如果用户把这些高级语法写进 ~/.profile，当系统其他组件用 sh 或 dash 读取这个文件时，就会直接报错。

为什么设计为互斥隔离（只读找到的第一个）？ 如果 Bash 依次把这三个全读一遍，往往会引发灾难（比如环境变量 PATH=...:$PATH 被重复追加三次、打印了三次登录欢迎语、或者因为语法不兼容报错）。在 Bash 开发者的视角里：

如果你写了专属的 .bash_profile，我就按你的来；如果你没写，我就去看你是不是习惯用 .bash_login；如果你连这都没写，那我就去读最普通的 .profile 保底。千万别读两次。

但这导致了一个巨大的痛点：用户必须在 login 和 non-login 两个文件里维护两套配置。为了解决这个问题，现代的 Linux 发行版（如 Ubuntu, CentOS, Debian）在默认给用户生成家目录（从 /etc/skel/ 拷贝）时，动了一个非常聪明的“手脚”——强制桥接。现代发行版真实的 Login Shell 读取顺序变成了一个嵌套链条：

1. bash 加载 /etc/profile -> 遍历并 source /etc/profile.d/*.sh （用于配置系统级环境变量）和去读 /etc/bash.bashrc
2. bash 去找并读取 (~/.bash_profile > ~/.bash_login > ~/.profile) -> 去读 ~/.bashrc

然而，想象如下情景：

1. 系统默认只有 ~/.profile（里面包含了调用 bashrc 的桥接代码）。
2. 你为了配置环境变量，上网随便搜了一篇教程，自己新建了一个 ~/.bash_profile 文件并在里面写了 export PATH=...。
3. 灾难发生：由于 Bash 的优先级是 ~/.bash_profile > ~/.profile，你的 Login Shell 发现了你新建的文件，就不会再去读系统的 ~/.profile 了。
4. 结果：你新建的文件里没有那段“桥接代码”，导致你的 ~/.bashrc 彻底被 Login Shell 抛弃，以前在 bashrc 里配的所有别名（alias）和变量在 SSH 登录时全部失效。

因此，上网查教程时要特别小心，尤其是你发现它在用>>（流追加符）这种看似无害的东西修改配置文件时，因为你永远不知道它究竟是简单的追加还是默默新建了一个优先级更高的配置。

zsh 读取顺序（macOS Catalina+ 默认）

zsh 无论是否 login，都读 ~/.zshrc，所以 zsh 下环境变量只需放在 ~/.zshrc 就够了——比 bash 简单得多。

怎么写

Windows

Windows GUI 程序改完环境变量后不会自动感知，需要重启该程序。虽然系统会广播 WM_SETTINGCHANGE 消息，但很多程序忽略此消息。可能可以通过重启程序或重新登录生效，但既然都是 Windows 了，最可靠的方式还是重启系统。

Linux

为什么有 /etc/profile 还要 /etc/profile.d/？

系统包更新可能覆盖 /etc/profile ，但 /etc/profile.d/ 下的文件独立存在不受影响。/etc/ 下很多配置其实都有 xxx 和 xxx.d/ ——以便分离默认配置和用户配置。

GUI 应用（从桌面环境启动的）不读 ~/.bashrc。

它们的进程由 display manager (如 GDM) 创建，继承的是 systemd 用户会话环境。给 GUI 应用设环境变量的正确方式：

此目录下的 .conf 文件格式同 /etc/environment（纯 KEY=VALUE），由 systemd-user 启动时读取，仅对 GUI 应用生效。

macOS

macOS Catalina (10.15) 起默认 Shell 从 bash 改为 zsh。

旧版升级后，~/.bash_profile 里的配置在新终端中完全不生效。迁移：把 bash 配置搬到 ~/.zprofile（login 级）+ ~/.zshrc（interactive 级）。

macOS 的 PATH 机制独特。

不在 /etc/environment 里（此文件不存在），而是用 /etc/paths + /etc/paths.d/。加系统级 PATH 目录的正确做法：

注意这里用 tee 而非流重定向符，是因为 sudo 只管命令运行权限，而流是由 Shell 处理的——用 sudo 不就是因为 Shell 权限不够嘛。你要用 sudo sh -c 'echo /opt/homebrew/bin >> /etc/paths.d/homebrew' 也是一样的。

GUI 应用（从 Dock/Launchpad 启动）不继承 Shell 环境变量。

macOS 的 GUI 应用由 launchd 启动，launchd 的环境来自系统级配置，不读 ~/.zshrc。给 GUI 应用设环境变量的正确方式：

PATH 设置最佳实践

各平台追加 PATH 的安全写法

动态库搜索——跨平台差异最大的领域

三平台机制速览

Windows DLL 搜索顺序

Windows 的 PATH 同时管可执行文件搜索和 DLL 搜索.

这是独一无二的：PATH 里加个目录，不光影响命令查找，还影响 DLL 加载。PATH 越宽，DLL 搜索范围也越宽，可能加载到错误版本 DLL（DLL Hell 的根源）。这也是为什么 Windows 下按个 Tab 会冒出来一堆不能直接运行的.dll.

SafeDllSearchMode 开启时（Windows Vista+ 默认）：

SafeDllSearchMode 关闭时（仅旧系统），当前目录排在 PATH 前面——这是安全隐患。

最佳实践：DLL 放在应用程序自己的目录下——这是搜索顺序第一位，最可靠且不影响其他程序。尽量不要依赖 PATH 来找 DLL。 这也就是为什么 Windows 下 FFmpeg 那么容易出问题：FFmpeg 的协议使其经常没法再分发，只能手动补齐。

Linux 动态库搜索

搜索顺序：

设置方法：

LD_LIBRARY_PATH 应当只临时使用。

LD_LIBRARY_PATH 不应永久写入 Shell 配置。它会覆盖 ldconfig 缓存和默认路径，可能导致系统工具加载到错误版本的库（比如你的 LD_LIBRARY_PATH 里有个旧版 libssl，系统 curl 就可能加载它然后崩掉）。

RPATH vs RUNPATH 行为不同。

RPATH 在 LD_LIBRARY_PATH 之前搜索（可被 RPATH 覆盖），RUNPATH 在之后搜索（LDLIBRARYPATH 可覆盖 RUNPATH）。现代 binutils 默认用 RUNPATH。如果你需要编译时路径覆盖环境变量，要显式用 -Wl,--disable-new-dtags（强制 RPATH）——但这通常不是你想要的。

$ORIGIN 是一个特殊的 rpath 值，展开为可执行文件所在目录。

用于可移植部署（可执行文件和库放同一目录树），但 $ORIGIN 必须写进 rpath 字面量，不能在 Shell 里展开——gcc 命令中要写成：

macOS 动态库搜索

搜索顺序：

macOS 的 @ 路径魔术——这是理解 macOS 动态库的关键：

macOS 的设计哲学：库的搜索路径编译进库本身（install name），而不是依赖环境变量。库的 install name 通常形如 @rpath/libfoo.dylib，加载时 dyld 用主程序的 rpath 列表展开 @rpath 为具体目录。

设置方法：

Homebrew 安装的库使用绝对路径 install name（/opt/homebrew/lib/libfoo.dylib 或 /usr/local/lib/libfoo.dylib），Homebrew 在编译时通过 -rpath 让可执行文件能找到它们。如果你手动编译程序链接 Homebrew 库，必须传：

漏了 -rpath 就能编译但运行时找不到库——这是 macOS 上 dyld: Library not loaded 报错的第一大原因。

install_name_tool 是 macOS 独有的神器：

可以修改已编译 .dylib 的 install name 和已编译可执行文件的 rpath，不需要重新编译：

经验交流：每个平台的环境和动态库问题都有大量隐坑，尤其是 Windows 的 DLL 搜索顺序和 macOS 的 install name 体系——如果你有踩坑经验或补充，欢迎评论区分享。