改完/etc/profile，随手source一下，当前终端里echo $MY_VAR输出正常，以为万事大吉。切到旁边那个早就开着的窗口，敲同样的命令，一片空白。再开一个终端，还是空白。最后重启机器，好了。这套流程我见过太多次，很多人的结论是"profile 有延迟"或者"必须重启才能生效"——这个结论是错的，而且会让你在真正需要排查的时候找错方向。source从来就没有"全局生效"这个能力，它只能改当前这一个 shell 进程自己的环境。所谓"全局"，需要你先定义清楚：你是想让所有新登录的用户拿到这个变量，还是想让已经跑着的进程也拿到，还是想让图形界面里点开的程序也拿到？这三个问题的答案、成本和做法完全不同。下面我按"先定位、再理解、后动手"的顺序，把这件事拆开讲清楚，适合被这个问题反复绊住的运维和开发同学。
1. 先分清"不生效"是哪一种不生效
1.1 四种典型症状，根因完全不一样
很多人一上来就说"profile 不生效"，其实这句话信息量几乎为零。我习惯先让提问的人做一个动作：把你期望生效的目标，按"它是什么进程、由谁拉起来的、什么时候启动的"描述一遍。因为同样是"变量不见了"，背后的原因能差出十万八千里。
| 症状 | 真正的原因 | 一句话验证 |
|---|---|---|
当前终端echo $VAR有值，别的已打开终端没有 | 环境变量不可横向传播，只对新起的子进程有效 | 在旧终端执行cat /proc/$$/environ对比 |
| 新开的终端也没有 | 新终端不是登录 shell，压根不读/etc/profile | shopt login_shell或看echo $0 |
| 图形桌面里点开的程序没有 | 桌面会话走的 PAM，不经过/etc/profile | 看会话进程的/proc/PID/environ |
| 服务、定时任务里没有 | systemd/cron 有独立的环境配置入口 | systemctl show 服务名 -p Environment |
这张表是我这些年反复用的一张"分诊表"。你会发现它有一个共同特征：问题从来不在"命令敲得对不对"，而在于"这个进程有没有机会读到那个文件"。source之所以让人产生幻觉，是因为它在你眼皮子底下生效了——当前终端立刻就能echo出来，反馈太即时，人就默认"写进去了"。可实际上，你改的只是这一个进程内存里的环境块。
1.2source到底动了什么东西
先把source（以及 POSIX 写法.）的行为说透。它做的事情是：在当前 shell 进程里，逐行读取并执行指定文件的命令。注意关键词——当前进程。它不是启动一个新 shell 去跑这个文件，所以文件里的cd、set、变量赋值都会留在当前 shell 身上；也正因为如此，文件里如果写了exit，会直接把你当前这个终端关掉，这是个经典的翻车点，后面还会讲。
那么"环境变量"在 Linux 里是什么？它是进程的一块内存区域，在execve调用时由父进程传给子进程。进程一旦被创建，它的环境块就定型了，父进程之后再怎么改自己的环境，也不可能"回头"去改已经存在的子进程。反过来，子进程修改自己的环境，更不可能影响父进程。
所以这里的逻辑链是这样的：
- 你在终端 A 里
source /etc/profile，终端 A 这个 shell 进程的环境块被改了； - 终端 A 之后启动的子进程（比如你在里面敲
python、make），会继承到新变量； - 终端 B 是另一个独立进程，它和终端 A 之间没有父子关系（它们的父进程通常是同一个会话管理器，比如
systemd --user或sshd），所以终端 B 完全看不到； - 终端 B 里已经跑着的那些子进程，同样看不到。
提示：判断"能不能看到某个变量"，永远问一句"它是不是在变量被设置之后，从那个被设置的进程 fork 出来的"。这比背任何配置文件路径都管用。
1.3 为什么大家会产生"全局"的错觉
因为PATH这类变量给我们的经验是"改了到处都在用"。但那是错觉——那些程序之所以能用上新 PATH，是因为它们都是在新的登录会话里启动的。真正的"全局"在 Linux 里其实不存在，只有"某个进程树范围内的传播"。
我见过最典型的误解是：把/etc/profile当成 Windows 的"系统环境变量设置界面"。两者的心智模型完全不同。Windows 那个界面写注册表，新启动的进程由系统在创建时统一注入；Linux 这边没有这样一个中央注入点，环境变量的传递是纯粹的进程继承。理解了这个差异，后面所有的"为什么"都会顺理成章。
2. 环境变量的传播路径：为什么"全局"是个伪概念
2.1 父子继承是唯一可靠的通道
Linux 中环境变量的传播只有一条正道：fork+execve时的继承。父进程把自己环境块的一份副本交给子进程，子进程在此基础上可以增删改，但这个修改只对"它自己以及它之后 fork 出来的后代"可见。
这条规则推导出几个非常实用的判断：
- 想影响新登录的用户：改
/etc/profile、/etc/profile.d/*.sh，因为新会话的登录 shell 会读它； - 想影响当前这个 shell 的所有后续操作：
source是有效的，因为当前 shell 是后续命令的父进程； - 想影响一个已经在运行的守护进程：没有任何优雅办法，只能重启它，或者走它自己的 reload 机制；
- 想影响一个和后端服务同级的兄弟进程：做不到，除非它们的共同父进程重新拉起它们。
我经常用一句话总结给新人："环境变量只会往下流，不会往上冒，也不会横着走。"上下游关系和进程树是绑死的，跟你是不是 root 没关系。哪怕你sudo su -变成 root，也只是新开了一个进程，那些"旧世界"的进程依然故我。
2.2 登录 shell 与非登录 shell 的分岔口
这是/etc/profile问题里最关键的一个机制。bash 启动时会根据"是不是登录 shell"决定读哪些启动文件：
| shell 类型 | 判定方式 | 会读的启动文件 |
|---|---|---|
| 登录交互 shell | login_shell为 on，或argv[0]以-开头（如-bash） | /etc/profile→/etc/profile.d/*.sh→~/.bash_profile/~/.bash_login/~/.profile（只读第一个存在的） |
| 非登录交互 shell | 普通打开终端、bash直接启动 | ~/.bashrc（Debian 系还会读/etc/bash.bashrc） |
| 非交互 shell | 脚本执行、bash -c | 通常什么都不读，除非设置了BASH_ENV |
| 网络登录 | sshd的PermitUserEnvironment | 同样走登录 shell 路径 |
现在解释一下你遇到的现象。很多发行版在图形界面下点开"终端"，启动的是非登录交互 shell，它压根不读/etc/profile，只读~/.bashrc。而 Debian/Ubuntu 的~/.bashrc里通常有一段：
# If not running interactively, don't do anything case $- in *i*) ;; *) return;; esac # 会去 source /etc/bash.bashrc但这段只处理交互判断，并不会反向去读/etc/profile。所以你的变量在图形终端里就是不出现。而你用 SSH 连上去、或者su -切换用户时，那是一个登录 shell，会读/etc/profile，变量就出现了。
这就是为什么同一个变量"SSH 上有、桌面终端没有"，很多人误以为跟用户权限有关，其实只是登录方式不同。
想立刻验证，可以这样：
# 看当前 shell 是不是登录 shell shopt login_shell # 看 argv[0] 前面有没有减号 echo "$0" # 强制以登录 shell 方式重新启动一个，测试变量是否出现 bash -l -c 'echo $MY_VAR'bash -l -c这个组合我在排查时用得非常多，它能一次性告诉你"如果它是登录 shell，变量到底能不能读到"，从而把"文件写错了"和"进程没读文件"这两种可能区分开。
2.3 绕开 profile 的三条暗河
即使你的 shell 是登录 shell，也还有三类进程根本不经过/etc/profile。这三条"暗河"是很多奇怪现象的根源。
第一条：systemd 系统服务。系统服务由 PID 1 拉起，PID 1 自己的环境是内核在引导早期给的，极其干净。服务如果想拿到变量，得在 unit 文件里显式声明：
[Service] Environment="MY_VAR=hello" # 或者从文件读 EnvironmentFile=-/etc/sysconfig/myappEnvironmentFile前面的减号表示文件不存在也不报错，这个小技巧在写可选配置时很有用。
第二条：计划任务。cron 执行任务时用的是极简环境，SHELL一般是/bin/sh，PATH是编译进去的默认值，其它变量基本没有。所以你在/etc/profile里定义的变量在 crontab 任务里是看不到的。正确的做法是在 crontab 顶部直接写：
SHELL=/bin/bash PATH=/usr/local/bin:/usr/bin:/bin MY_VAR=hello或者在任务脚本的第一行手动. /etc/profile。后者有个前提：那个脚本得是 bash 执行，而且/etc/profile内部不能有对非交互环境不友好的语句。
第三条：图形会话。GDM、LightDM、SDDM 这些显示管理器通过 PAM 建立会话，进程树是"显示管理器 → 会话 → 桌面环境 → 你点开的程序"。这条链路里没有任何一环会去读/etc/profile。想影响它，得用 PAM 那一套入口，详见第 4 节。
2.4 换个 shell 就等于换了一套启动文件
还有一个高频翻车场景：用户改的是/etc/profile，但他的登录 shell 是 zsh。zsh 的启动文件体系和 bash 不一样：
/etc/zshenv、~/.zshenv：所有zsh 实例都会读，包括非交互、非登录；/etc/zprofile、~/.zprofile：登录 shell 读；/etc/zshrc、~/.zshrc：交互 shell 读。
也就是说，如果你把变量写在/etc/profile，而用户的 shell 是 zsh，那么只有在"登录 shell"这一个场景下才会生效，而且还得是 zsh 编译时开启了读取/etc/profile的兼容选项（很多发行版默认不开）。这就是为什么同一台机器上，运维账号能看到变量，开发账号看不到——shell 不一样。
排查时永远先确认echo $SHELL和/etc/passwd里该用户的登录 shell，再看对应 shell 的文档。这一步花十秒，能省下半小时。
3. 排查链路：从 /proc 反推环境变量的来源
3.1 先看进程真实环境，而不是 echo
echo $VAR只反映当前 shell 的认知，它有三个局限：看不到别的进程、看不到已被unset的历史、看不到变量是否被 export 过。真正权威的是内核为你保存的那份环境快照。
# 查看当前 shell 进程的真实环境（注意用 \0 分隔） tr '\0' '\n' < /proc/$$/environ | sort # 查看任意进程的环境 tr '\0' '\n' < /proc/<PID>/environ | grep -i my_var # 更直观的写法 xargs -0 -L1 -a /proc/$$/environ这里有个非常重要的细节：/proc/PID/environ反映的是进程启动那一刻（更准确地说，是最近一次 execve 时）的环境。如果进程启动之后自己putenv修改过，这个文件不会更新。所以它有时会和进程内部实际看到的不一致——通常表现为"文件里有，程序里没有"，这多半是程序内部做了清理，或者文件被后续逻辑覆盖了。
/proc/PID/environ还是只读的。我见过有人想通过写这个文件来给运行中的进程加变量，写不进去，还会得到Permission denied。这不是权限问题，是内核设计如此。
3.2 判断当前 shell 是不是登录 shell
这一步是整个排查的枢纽。我通常按顺序做四个检查：
# 1. 是不是登录 shell shopt login_shell # 2. 看 argv[0]，登录 shell 通常前面有减号 echo "$0" # 3. 看 shell 选项里有没有 i（交互） echo "$-" # 4. 看当前用户的登录 shell 是哪个 getent passwd "$USER" | cut -d: -f7这四个输出组合起来，基本能定性。比如shopt login_shell是off，$-里有i，那就明确是"非登录交互 shell"，不读/etc/profile是符合预期的，不是 bug。
如果想进一步确认"到底读了哪些文件"，可以在 bash 启动时加-x跟踪：
bash -l -x -c 'true' 2>&1 | head -50这个输出会把登录 shell 读取的每一个文件、每一行命令都打出来。想找/etc/profile到底执行到哪、在哪一步提前退出了，这是最直接的手段。
3.3 检查 profile 内部的条件分支与执行顺序
即使 shell 是登录 shell，/etc/profile内部也可能因为条件判断而跳过你的配置。常见的几类：
一是交互性判断。很多发行版的/etc/profile开头会有类似：
if [ "${-#*i}" != "$-" ]; then # 只有交互 shell 才执行 fi或者更简单粗暴的：
if [ -n "$PS1" ]; then ... fi这些写法会让非交互的登录 shell（比如bash -l -c 'xxx'）跳过后续内容。如果你正好把变量写在这段里面，那通过 SSH 交互登录能看到，通过脚本调用就看不到。
二是 profile.d 的加载方式。CentOS/RHEL 系的/etc/profile末尾通常是：
for i in /etc/profile.d/*.sh /etc/profile.d/sh.local; do if [ -r "$i" ]; then if [ "${-#*i}" != "$-" ]; then . "$i" else . "$i" >/dev/null fi fi done unset i这里有几个坑：只匹配*.sh，文件名不以.sh结尾的文件不会被加载；循环变量i用完会unset，所以你在自己的脚本里千万不要依赖外部传入的i；如果某个脚本里有语法错误，后面的脚本可能受影响。
三是执行顺序导致的覆盖。/etc/profile之后，还有~/.bash_profile、~/.bash_login、~/.profile（按顺序取第一个存在的），以及用户自己~/.bashrc。如果你的变量在/etc/profile里被设成 A，用户家目录里有段逻辑把它改成 B，那你看到的永远是 B。这种"明明改了系统文件却不生效"的情况，九成是被用户级配置覆盖了。
3.4 一条完整的排查记录
讲个真实的例子。某台服务器上，JAVA_HOME通过/etc/profile.d/java.sh设置，运维张三在 SSH 里登录后echo $JAVA_HOME正常，但同一台机器上另一个同事李四的账号死活拿不到。我们按下面的顺序走了一遍：
# 第一步：确认症状范围 su - lisi -c 'echo $JAVA_HOME' # 空 su - zhangsan -c 'echo $JAVA_HOME' # 有值同一条命令，同样的登录方式，结果不同，说明问题不在系统文件，而在用户维度。
# 第二步：看登录 shell 差异 getent passwd lisi | cut -d: -f7 # /bin/zsh getent passwd zhangsan | cut -d: -f7 # /bin/bash找到了。李四的 shell 是 zsh，而/etc/profile.d/里的脚本是给 bash 登录 shell 用的。zsh 作为登录 shell 不会自动读/etc/profile（Debian 系的 zsh 有时会在/etc/zprofile里 source/etc/profile，这台机器上没有）。
# 第三步：验证 zsh -l -c 'echo $JAVA_HOME' # 空，符合预期 bash -l -c 'echo $JAVA_HOME' # 有值，符合预期结论清楚，解决方案有两个：要么把变量挪到一个所有 shell 都能读的位置（比如/etc/environment），要么在/etc/zprofile里补一段加载逻辑。我们选了后者，改动最小。
这个例子的价值在于：排查的方向不是"变量怎么丢的"，而是"谁的启动路径和别人的不一样"。一旦你有了"按进程启动路径反推"的思维，这类问题的定位速度会快一个数量级。
4. 对症下药：四种场景的落地改法
4.1 只想让新开的终端生效：profile.d 拆分加幂等写法
如果目标只是"所有新登录的 bash 用户体验到新变量"，最干净的做法不是直接改/etc/profile，而是在/etc/profile.d/下新建一个独立文件。
# /etc/profile.d/myapp.sh export MYAPP_HOME=/opt/myapp export PATH="${MYAPP_HOME}/bin:${PATH}"为什么推荐拆文件而不是改主文件？
- 升级安全：发行版升级有时会覆盖
/etc/profile，独立文件不在覆盖范围内； - 职责清晰：每个应用一个文件，出问题容易定位是哪一段；
- 方便启用禁用：改后缀或加
if判断就能临时关掉； - 团队协作友好：配置文件进版本管理时，diff 干净。
写这个文件时有几个细节值得注意。第一是必须用export，否则变量只是当前 shell 的局部变量，子进程拿不到。第二是PATH 拼接要保留原值，写成PATH="/opt/myapp/bin"会把系统默认路径冲掉，那时连ls都可能找不到。第三是幂等性，如果同一个脚本可能被 source 多次，最好加个守卫：
# /etc/profile.d/myapp.sh if [ -z "${MYAPP_HOME}" ]; then export MYAPP_HOME=/opt/myapp export PATH="${MYAPP_HOME}/bin:${PATH}" fi第四是权限，文件建议644、属主root:root。因为/etc/profile的执行上下文可能包含 root 会话，谁都能写的脚本等于一个提权入口，这是实打实的安全问题，不是洁癖。
最后是尾缀必须是.sh。前面说过 RHEL 系的加载循环只匹配*.sh，你写个myapp.conf放进去，功能性上完全没用，还不容易发现。
4.2 图形桌面里启动的程序怎么拿到变量
桌面会话走 PAM，所以入口在 PAM 环境配置这一侧。最常用的是/etc/environment：
# /etc/environment MYAPP_HOME=/opt/myapp这个文件有两个重要限制：不支持变量展开（你写PATH=$PATH:/opt/myapp/bin不会被解析，$PATH会被当成字面量），不支持 shell 语法（不能写if、不能写注释以外的东西，实际上连注释支持都很有限）。它只做最简单的KEY=value逐行解析。
复杂场景可以走/etc/security/pam_env.conf，语法更灵活：
# /etc/security/pam_env.conf MYAPP_HOME DEFAULT=/opt/myapp OVERRIDE=/opt/myapp注意DEFAULT只在变量未设置时生效，OVERRIDE强制覆盖，这个区别很实用。
对于 systemd 管理的用户会话，还有~/.config/environment.d/*.conf这套机制（需要较新版本的 systemd）：
# ~/.config/environment.d/myapp.conf MYAPP_HOME=/opt/myapp改完之后必须重新登录桌面会话，注销再登录，不是重启程序就行。因为 PAM 环境是在会话建立那一刻注入的，前面说的父子继承规则在这里同样适用。
4.3 systemd 服务与计划任务的环境配置
服务这块最忌讳的做法是"在服务脚本里手写. /etc/profile"。原因很实在：/etc/profile里通常包含大量针对交互 shell 的逻辑（提示符设置、别名、/etc/profile.d全量加载），在服务上下文里执行既慢又容易报错，还会把一堆无关变量塞进服务环境。正确做法是让 unit 文件自己声明：
[Unit] Description=My App [Service] Type=simple Environment="MYAPP_HOME=/opt/myapp" Environment="LANG=en_US.UTF-8" EnvironmentFile=-/etc/sysconfig/myapp ExecStart=/opt/myapp/bin/start.sh改完之后执行：
systemctl daemon-reload systemctl restart myapp systemctl show myapp -p Environmentdaemon-reload这步经常被忘，改了 unit 文件不 reload，服务还是按旧配置跑，然后你会怀疑自己没改对。
有一点要特别提醒：Environment=里不做 shell 展开。写Environment="PATH=$PATH:/opt/myapp/bin"无效，$PATH是字面量。想扩展现有 PATH，得把完整路径写死，或者干脆在ExecStart里用绝对路径调用。
计划任务这边更简单，直接在 crontab 顶部声明：
# 系统级 /etc/cron.d/myjob SHELL=/bin/bash PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin MYAPP_HOME=/opt/myapp */5 * * * * root /opt/myapp/bin/task.sh用户级 crontab 也可以同样写。注意/etc/cron.d/里的文件格式多一列用户名，格式写错会导致整个文件被忽略，这是个很隐蔽的坑。
4.4 已经跑起来的进程还有救吗
直说：没有干净的办法。/proc/PID/environ只读，没有接口能让运行中的进程"重新读一遍环境变量"。有三个方向可以尝试，但都有代价：
方向一：进程自带的 reload 机制。有些服务支持SIGHUP或systemctl reload重新加载配置，如果它的配置里包含环境相关逻辑，可能生效。但这取决于具体实现，不能想当然。
方向二：重启进程。最稳的做法。对于桌面程序，就是关掉再打开；对于服务，就是systemctl restart。重启的成本要评估，但比起折腾各种奇技淫巧，通常是最省时间的。
方向三：调试注入。用gdbattach 到目标进程，调用putenv()。这个做法我只在调试场景用过，生产环境绝对不建议：会影响进程稳定性，可能触发崩溃，而且某些语言的运行时（比如 Go、Java）根本不通过 libc 的getenv读取环境，注入了也读不到。
# 仅供调试参考，生产不要用 gdb -p <PID> -batch \ -ex 'call (int)putenv("MY_VAR=test")' \ -ex 'detach'我踩过的坑是：注入之后在/proc/PID/environ里看不到这个变量，因为那个文件反映的是 execve 时的快照，不会因为putenv更新。所以"注入没生效"这个判断，得靠进程自己的行为来验证，不能靠读/proc。这一点很容易误导人，第一次踩的时候我盯着environ看了半小时。
5. 几个容易翻车的细节
5.1export漏写是最常见的低级错误
这个错误极其常见，因为表现形式很迷惑：
# 错误写法 MY_VAR=hello # 正确写法 export MY_VAR=hello不加export，变量只在当前 shell 里可见，任何子进程都拿不到。症状是"在终端里echo $MY_VAR有值，但脚本里echo $MY_VAR是空"。很多人第一反应是"脚本没执行到设变量的地方"，实际上变量就在那里，只是没导出。
已经定义过的变量可以事后补一次导出：
MY_VAR=hello echo $MY_VAR # hello bash -c 'echo $MY_VAR' # 空，因为没导出 export MY_VAR bash -c 'echo $MY_VAR' # hello判断一个变量有没有被导出，可以用export -p看导出的列表，或者用declare -p MY_VAR，输出里带-x标记的就是导出的。
5.2 变量被后加载的脚本悄悄覆盖
Linux 的启动文件是按顺序执行的，后面的会覆盖前面的。典型顺序（bash 登录 shell）：
/etc/profile └── /etc/profile.d/*.sh /etc/bash.bashrc (部分发行版) ~/.bash_profile (或 ~/.bash_login，或 ~/.profile，取第一个存在的) ~/.bashrc (如果被上面的文件 source 了)如果你的变量在/etc/profile.d/里设为 A，而用户家目录的~/.bash_profile里又设了一次 B，最终看到的就是 B。排查方法是在用户家目录里搜一遍：
grep -rn "MY_VAR" /home/用户名/.[a-z]* 2>/dev/null还有一个更隐蔽的情况：同一个变量在不同文件里用不同方式定义。比如/etc/profile.d/a.sh里是export PATH="$PATH:/opt/a/bin"，~/.bashrc里是PATH="/usr/bin:/bin"，后者会把前者的路径直接抹掉。这类问题只能靠"完整梳理一遍加载链"来发现，没什么捷径。
5.3source里的exit和set -e会关掉你的终端
前面提过，source是在当前 shell 执行脚本，所以脚本里的exit会退出当前 shell。为什么这个值得单独说？因为/etc/profile里如果有一句条件判断失败后直接exit，你source /etc/profile时就会莫名关掉终端。
还有set -e（遇错即退）也一样危险。如果某个 profile.d 脚本里有这么一段：
set -e some_command_that_might_fail set +e中间那句一旦返回非零，整个 shell 就退出了。而你在交互终端里来源执行它，效果就是终端一闪就关。
注意：写
/etc/profile.d/里的脚本，尽量不要用set -e，如果确实需要，务必在条件中允许失败，例如cmd || true。
顺带说一个相关的行为差异：source是 bash 的内建命令，.是 POSIX 的定义，功能等价。在某些 shell（比如 dash）里只有.，source会报not found。写脚本要用.；在交互终端里图方便用source没问题。
5.4 权限、换行符与编码
三个看起来小、实际很烦的坑。
权限问题。/etc/profile.d/下的文件被加载时，加载逻辑里通常有if [ -r "$i" ]判断，所以至少需要可读权限。但更需要注意的是不要给它写权限。因为这段脚本会在管理员会话里执行，任何能改写它的用户都等于能执行任意代码。
换行符问题。从 Windows 传过来的脚本常带 CRLF 换行，bash 执行时会报各种莫名其妙的错，比如bash: $'\r': command not found。检查方法：
file /etc/profile.d/myapp.sh # 如果输出里有 "with CRLF line terminators"，就是这个问题 # 转换 sed -i 's/\r$//' /etc/profile.d/myapp.sh编码与引号。变量值里如果包含空格、中文、特殊字符，一定要加引号。尤其在 PATH 拼接时，写export PATH=$PATH:/opt/my app/bin会因为空格断成两段，后半段还可能被 shell 当成命令。规范写法：
export PATH="${PATH}:/opt/my app/bin"另外中文字符串在某些LANG没设置好的环境里可能乱码，如果变量值要参与路径拼接，建议全 ASCII。
6. 一份可以直接贴在工位上的自查清单
排查这类问题，我总结了一套固定的动作顺序，按这个顺序走基本不会漏：
第一步，明确目标进程。到底是"新登录的用户"、"当前终端"、"图形程序"还是"系统服务"？不同的目标对应完全不同的写入位置，这一步没想清楚，后面全是白费。
第二步，看进程真实环境。
tr '\0' '\n' < /proc/<目标PID>/environ | sort第三步，判断 shell 类型。
getent passwd "$USER" | cut -d: -f7 # 登录 shell shopt login_shell # 是否登录 shell echo "$-" # 是否交互第四步，梳理加载链。bash 登录 shell 的完整路径是/etc/profile→/etc/profile.d/*.sh→~/.bash_profile。用bash -l -x -c 'true' 2>&1 | grep -i profile可以直接看到它实际读了哪些文件。
第五步，验证变量是否导出。declare -p VAR看有没有-x标记。
第六步，针对场景选入口。终端用户 →/etc/profile.d/*.sh；图形会话 →/etc/environment或 PAM 配置；服务 → unit 文件的Environment=；定时任务 → crontab 顶部。
第七步，重启对应的父进程。shell 类重新打开终端或重新登录；服务类daemon-reload+restart；图形会话注销重登。
这张清单的价值在于，它把"我以为"转换成了"我验证过"。/etc/profile和source的坑，本质上都是"人的直觉和进程模型的直觉不一致"导致的。
我个人的体会是，环境变量这个领域没有真正意义上的"全局"，只有"谁从谁继承"。每次遇到变量不生效，不要急着问"文件改对了吗"，先问"这个进程是从哪儿来的、它的父进程是谁、它在什么时候启动的"。这三个问题的答案，往往在你打开编辑器之前，就已经把问题解决了一大半。剩下那一小半，交给上面那张清单就够了。
