环境变量作用范围取决于配置位置与加载方式：/etc/environment纯键值对、无shell语法，适用于LANG等静态变量；/etc/profile支持export和动态拼接，需source或重新登录生效；用户级推荐~/.profile中source ~/.bashrc以统一管理；systemd服务须用Environment或EnvironmentFile，不可依赖shell配置。
环境变量在 Linux 中不是“配了就全局生效”，它的作用范围完全取决于你写在哪、怎么加载、由谁加载——搞错位置，export 再多次也没用。
系统级配置：/etc/environment 与 /etc/profile 的本质区别
/etc/environment 是 PAM 系统读取的纯键值对文件，不支持变量展开、不执行 shell 语法，连 $PATH 这种引用都会原样保留；而 /etc/profile 是 shell 启动时执行的脚本，支持 export、条件判断和命令替换。
- 需要让所有用户（包括 cron、systemd 服务）都继承的变量（如
LANG），优先写进/etc/environment - 需要动态拼接路径（如
export PATH="/opt/mybin:$PATH"）或依赖当前 shell 特性的，必须用/etc/profile或其子文件（如/etc/profile.d/*.sh） - 修改
/etc/environment后，新登录会话才生效；修改/etc/profile后，需重新登录或手动source /etc/profile
用户级配置：~/.bashrc、~/.profile 和 ~/.bash_profile 怎么选
普通用户日常最常改错的地方：以为改了 ~/.bashrc 就能影响图形界面终端或 SSH 登录后的所有环境——其实不一定。不同 shell 启动模式加载不同文件：
- 交互式非登录 shell（如 GNOME 终端里新开一个 tab）→ 只读
~/.bashrc - 交互式登录 shell（如 SSH 登录、TTY 登录）→ 先读
~/.bash_profile，若不存在则读~/.profile；两者都不加载~/.bashrc，除非你显式写source ~/.bashrc - 所以稳妥做法是：在
~/.profile末尾加一行source ~/.bashrc，再把所有export都挪到~/.bashrc
临时生效与调试：为什么 echo $PATH 看不到刚 export 的变量
常见现象：在终端里敲了 export MY_VAR=abc，接着运行某个脚本却读不到——因为该脚本可能是以非继承方式启动（如通过桌面快捷方式、crontab 或 systemd service 启动），根本没走当前 shell 环境。
- 确认变量是否真的导出：
env | grep MY_VAR（比echo $MY_VAR更可靠，排除别名或局部变量干扰） - 检查进程继承链：
ps -f看目标进程的 PPID，再用cat /proc/<pid>/environ | tr '\0' '\n'查它实际看到的环境 - 临时测试某变量对命令的影响：
MY_VAR=abc command --help（只对该命令生效，不污染当前 shell）
systemd 服务中设置环境变量的正确姿势
systemd 不读 shell 配置文件，EnvironmentFile 或 Environment= 是唯一可控入口。直接在 service 文件里写 ExecStart=/bin/sh -c 'export MY_VAR=1; mycmd' 是无效的——export 在子 shell 里生效后就退出了。
Environment="MY_VAR=production" EnvironmentFile=-/etc/default/myservice ExecStart=/usr/bin/myservice
-
EnvironmentFile路径前加-表示“不存在也不报错” - 文件内容必须是
KEY=VALUE格式，不能有空格、注释或export前缀 - 如果变量值含空格或特殊字符，用双引号包裹：
LOG_DIR="/var/log/my app"
真正麻烦的从来不是“怎么写 export”，而是搞清哪个进程在哪个阶段读哪份配置——尤其当 GUI 应用、后台服务、SSH 会话混用同一套变量时，漏掉一次 source 或写错一个启动类型，就会卡住半天。
