Linux怎么配置环境变量的优先级

环境变量的覆盖规则，说白了就一条——谁后加载，谁说了算。后读取的配置文件里如果定义了同名变量，就会直接盖掉前面的值。用户级配置（比如 `~/.bashrc`）最常用，也最容易生效；而系统级文件（像 `/etc/profile`）加载得早，反倒容易被后面的用户文件覆盖。

环境变量的优先级由加载顺序决定，不是“设置得越靠前越优先”

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，一看就清楚了。