export设置的环境变量仅对当前shell及其子进程有效，因Unix进程隔离机制决定其无法跨终端或父shell生效；永久生效须写入~/.bashrc等初始化文件并source或重启会话。
Linux 中变量默认不跨环境——子 Shell、新终端、脚本执行时都看不到你当前终端里定义的 VAR=value。要让它“跨”，本质是让变量变成**环境变量**，并确保它在目标环境中被加载。
为什么 echo $VAR 在新终端里为空
因为你只做了局部赋值：MY_PATH=/opt/myapp，这变量只存在于当前 Shell 进程，不会自动传给子进程或新会话。Shell 启动时不会读取上一个终端的变量状态，也没有“全局内存”共享机制。
- 新开终端 = 全新登录 Shell → 仅加载
~/.bashrc或/etc/environment等配置文件里的内容 - 执行脚本（如
./test.sh）= 启动子 Shell → 只继承已 export 的环境变量 -
bash命令进入子 Shell → 同样只继承 export 过的变量
export 变量后仍不跨终端？检查加载路径
export MY_VAR=value 只对当前会话及它的子进程有效，关掉终端就丢。想跨终端，必须把 export 行写进 Shell 启动配置文件，并确认该文件确实被加载。
- 交互式非登录 Shell（如 GNOME 终端、Xshell 打开的窗口）默认只加载
~/.bashrc - 登录 Shell（如 SSH 登录、
su -）按顺序加载：/etc/profile→~/.bash_profile→~/.profile→ 最后可能 source~/.bashrc - 如果你只改了
~/.bash_profile，但没让它 source~/.bashrc，而你日常用的是图形终端，那修改就根本没生效
验证方法：echo <p>验证方法：<code>echo $0 看是否为 -bash（登录 Shell），再用 grep -n "MY_VAR" ~/.bashrc ~/.bash_profile ~/.profile 2>/dev/null 定位写在哪，最后 source ~/.bashrc 测试是否立即可用。
-bash（登录 Shell），再用 grep -n "MY_VAR" ~/.bashrc ~/.bash_profile ~/.profile 2>/dev/null 定位写在哪，最后 source ~/.bashrc 测试是否立即可用。
PATH 追加写错导致命令找不到
这是最常踩的坑：写成 export PATH=/my/bin 覆盖了原有 PATH，结果连 ls 都报 “command not found”。正确做法永远是拼接：
export PATH=$PATH:/my/bin
- 注意
$PATH前后不能有空格，否则 Bash 会把它当两个参数 - 路径末尾不要加斜杠（
/my/bin/是错的），虽然多数情况能工作，但某些工具（如which）可能异常 - 如果要优先使用自定义命令，把新路径放前面：
export PATH=/my/bin:$PATH
/etc/environment 里不能用 $PATH 展开
这个文件由 PAM 直接读取，不经过 Shell 解析，所以不支持变量展开、命令替换或 export 语法。写进去的内容必须是纯静态键值对：
JAVA_HOME="/usr/lib/jvm/java-11-openjdk-amd64" PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/opt/myapp/bin"
- 不能写
PATH="$PATH:/opt/myapp/bin"—— 这会被当成字面量字符串，$PATH 不展开 - 不能写
export JAVA_HOME=...—— export 关键字直接报错或被忽略 - 修改后需重新登录（不是
source）才生效，且影响所有用户
真正容易被忽略的是：不同 Shell（bash/zsh）、不同登录方式（GUI 终端 vs SSH）、不同发行版（Ubuntu 的 /etc/environment 加载行为和 CentOS 有细微差异），会导致同一行配置在一台机器生效，在另一台静默失效。别假设“写进 .bashrc 就万事大吉”，先 echo $SHELL 和 ps -p $$ 确认当前 Shell 类型和会话类型。
