系统级环境变量真正全局生效的只有/etc/environment，由pam直接读取，对所有用户及进程（含systemd服务、gui应用）生效；/etc/profile及其profile.d/*.sh仅在登录shell（如ssh、tty）时加载，非登录shell和gui应用通常不读取。
系统级环境变量到底影响谁？
系统级环境变量不是“所有进程无条件继承”，而是取决于加载时机和 Shell 类型。真正全局生效的只有 /etc/environment；/etc/profile 和 /etc/profile.d/*.sh 只在登录 Shell（如 SSH、TTY 登录、su -）时加载；非登录 Shell（如 GNOME 终端新标签页、su user）默认不读它们。
/etc/environment 为什么最“硬核”但限制最多？
这个文件由 PAM 直接读取，不经过 Shell 解释器，所以它：
- 不支持
$PATH展开、命令替换或任何 Shell 语法 - 必须用纯
KEY=VALUE格式，例如：JAVA_HOME="/usr/lib/jvm/java-11-openjdk" - 对所有用户、所有进程（包括 systemd 服务、GUI 应用）都生效，但需重启会话或系统才能加载
- 无法追加值，比如不能写
PATH="$PATH:/opt/myapp/bin"—— 这会直接报错或被忽略
/etc/profile 和 /etc/profile.d/*.sh 的实际行为差异
/etc/profile 是登录 Shell 启动时第一个执行的脚本，但它本身不保证所有子进程都能继承变量 —— 关键看是否被后续 Shell 配置覆盖。更推荐用 /etc/profile.d/：
- 新建文件如
/etc/profile.d/myapp.sh，内容只需：export MYAPP_HOME="/opt/myapp" - 无需
chmod +x，只要以.sh结尾，/etc/profile就会自动source它 - 避免直接修改
/etc/profile，防止系统升级时被覆盖 - 注意：如果用户
~/.bashrc中重写了同名变量（比如又定义了PATH），那系统级设置会被覆盖
验证是否真生效，别只信 echo $VAR
很多变量看似设置了，但在子进程里拿不到。正确验证方式：
- 新开终端或重新 SSH 登录后，运行
env | grep MY_VAR—— 确保出现在输出里 - 测试子进程继承：
bash -c 'echo $MY_VAR'，如果为空，说明没导出或没加载 - 检查是否被覆盖：
declare -p | grep MY_VAR，看是declare -x（已导出）还是declare --（仅局部） - GUI 应用（如 VS Code、Firefox）通常不读
/etc/profile，得靠/etc/environment或桌面环境 session 配置
