环境变量的优先级由加载顺序决定，并非“设置越靠前越优先”
Linux 中环境变量并没有统一的“优先级数值”，其覆盖行为完全取决于 shell 启动时读取配置文件的先后顺序——后读取的文件中通过 export 定义的同名变量会直接覆盖前面的值。举例来说：在 ~/.bashrc 中写入 export PATH=/a:$PATH，又在 ~/.bash_profile 中写入 export PATH=/b:$PATH，最终生效的是后者，前提是它被加载并执行得更晚。
很多人误以为“系统级优先级高于用户级”，事实恰恰相反。用户级配置（尤其是 ~/.bashrc）几乎每次新开终端都会加载，而系统级的 /etc/profile 只在登录 shell 启动时读取一次，并且很可能被后续的用户配置覆盖。
~/.bashrc：交互式非登录 shell（例如日常打开的 GNOME 终端）一定会读取，是**最常用、最容易生效的位置**。~/.bash_profile：仅在登录 shell（如 SSH 登录、图形界面首次登录）时读取。如果该文件存在，它通常会主动source ~/.bashrc，否则两边互不影响。/etc/profile和/etc/environment：属于系统级配置，所有用户共享，但加载时间较早，容易被用户文件覆盖。特别注意/etc/environment不支持export或变量展开，只能写入KEY=VALUE这种纯静态格式。- 命令行直接执行
export VAR=value：**拥有最高优先级**，但仅对当前 shell 及其子进程生效，关闭终端后失效。
为什么 source ~/.bashrc 后 echo $PATH 没有变化？
遇到这个问题通常不是优先级导致，而是变量根本没有被正确设置。常见踩坑点包括：
- 变量名拼写错误：例如把
PATH写成了PATHH，或者大小写混淆（path与PATH是两个不同变量）。 - 遗漏
export：只写了PATH=$PATH:/my/bin——这样定义的变量是 shell 内部变量，不会传递给子进程。 - 路径拼接时使用了单引号：
export PATH='$PATH:/my/bin'会导致$PATH未展开，直接变成字面字符串。 ~/.bashrc被其他逻辑跳过：某些发行版（如 Ubuntu）默认的~/.bashrc开头包含[ -n "$PS1" ] || return，在非交互式 shell 中会直接退出，不执行后续内容。
验证变量是否写入的方法：执行 grep -n "export.*PATH" ~/.bashrc 检查语句是否存在且未被注释；再运行 set | grep "^PATH="，确认输出中已包含你添加的路径。
如何安全地追加 PATH 而不破坏原有值？
直接写 PATH=... 而不保留原值是高风险操作——一旦覆盖，连 ls、cd 等基础命令都会无法找到。正确做法是保留原值并进行拼接：
- 标准写法：
export PATH="$PATH:/home/user/myapp/bin"（推荐使用双引号，以避免路径中存在空格导致的问题） - 避免写成：
export PATH="/home/user/myapp/bin:$PATH"。虽然语法正确，但会将自定义路径放在最前面，可能意外覆盖系统命令（例如本地编译的python位于 bin 目录下，就会绕过系统自带的 Python）。 - 如果确实需要让某条路径优先（例如调试时使用 mock 工具），可以用
export PATH="/tmp/mockbin:$PATH"，但务必清楚这种做法带来的影响。 - 临时测试时，还可以使用
PATH="/tmp/testbin:$PATH" command，这样仅对单条命令生效，不会影响当前 shell 的环境。
为什么 systemd 服务或 crontab 中的环境变量不生效？
因为它们并不会读取你的 ~/.bashrc。systemd 服务默认只有极简的环境变量（PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin），crontab 的情况也类似。
- systemd：在 service 文件的
[Service]段中通过Environment="PATH=/usr/local/bin:/usr/bin:/bin:/my/app/bin"显式定义，或使用EnvironmentFile=/path/to/env.conf加载外部配置。 - cron：在 crontab 条目开头直接设置环境变量，例如：
PATH=/usr/local/bin:/usr/bin:/bin:/my/app/bin * * * * * /my/app/script.sh - 切勿依赖
source ~/.bashrc——cron 默认使用/bin/sh，不一定支持 bash 特性，且~在非交互环境中可能解析失败。
最容易忽略的关键点在于：不同场景下的 shell 类型（bash/zsh/sh）各不相同，它们加载的初始化文件也完全不同。不要想当然地认为“在终端里能运行，在服务里也能跑”。验证方法非常简单——直接在目标上下文中运行 printenv PATH 或 env | grep MYVAR，结果一目了然。
