结论：用 env 查已导出的环境变量，echo $VAR 不反映是否导出；declare -p VAR 验证是否 export；子进程仅继承 export 变量；bash -c 'echo $VAR' 测试继承性；图形终端可能未加载 ~/.bashrc。
直接看结论：用 env 查当前 shell 已导出的环境变量（子进程能继承的部分），但若发现变量“设了却没生效”，大概率是没 export、拼写错误、或配置未重新加载——不能只信 echo $VAR，它不告诉你变量是否被导出。
为什么 echo $PATH 显示正常，但程序却找不到命令？
因为 echo $PATH 只显示变量值，不验证它是否被导出为环境变量。子进程（比如你运行的 ls 或 python）只能继承 export 过的变量。
- 检查是否导出：
declare -p PATH—— 输出含declare -x PATH=...才算真正生效 - 常见漏点：
PATH=/new/bin:$PATH写了但没加export PATH，此时env | grep PATH查不到 - 大小写陷阱：
echo $path在 bash 下永远为空，标准变量名是PATH；echo $JAVA_HOME拼成java_home也查不到 - 临时补救：已赋值但未导出？直接运行
export PATH即可，无需重写赋值语句
env 和 printenv 看起来一样，该选哪个？
二者输出内容一致，但行为边界不同：
-
env是通用环境管理命令，还能干别的事，比如临时清掉某个变量再运行程序：env -u LD_LIBRARY_PATH ./myapp -
printenv更专一，查单个变量更安全：printenv JAVA_HOME返回空，就说明变量未设置（而echo $JAVA_HOME在变量未定义时可能报错或输出空行） - 查多个变量：
printenv HOME USER SHELL一行命令全输出，env不支持这种用法 - 兼容性注意：某些最小化系统（如 Alpine 的 busybox）里
printenv可能不可用，但env几乎总在
怎么确认某个变量在子进程中真的可用？
别只看当前 shell，要验证继承性——这才是“生效”的本质。
- 最简测试：
bash -c 'echo $MY_VAR'，如果输出值，说明它已被导出且子 shell 能访问 - 对比测试：
set | grep '^MY_VAR='有输出但env | grep '^MY_VAR='没输出 → 局部变量，未导出 - 路径类变量（如
PATH）建议配合command -v验证：command -v mytool是否命中你新增的目录，比单纯看$PATH字符串更可靠 - 注意：图形界面启动的终端（如 GNOME Terminal）可能不 source
~/.bashrc，导致你在里面写的export实际没加载——改完记得source ~/.bashrc或新开一个 login shell 测试
查进程实际拿到的环境变量，不是当前 shell 的
调试服务、容器或后台进程时，它启动时继承的环境可能和你现在 shell 完全不同。
- 查当前 shell 进程的原始环境：
tr '\0' '\n' （<code>$$是当前 shell 的 PID） - 查其他进程（如 nginx）：
pgrep nginx | head -n1 | xargs -I{} sh -c 'tr "\0" "\n" - 权限限制：非 root 用户无法读取其他用户进程的
/proc/PID/environ，会提示Permission denied - 关键点：这个文件反映的是进程启动瞬间的快照，后续
export修改不影响它 —— 所以服务 reload 后必须重启进程才能更新其环境
真正容易被忽略的不是命令怎么敲，而是变量作用域的分层：shell 层、登录 session 层、PAM 层（/etc/environment）、systemd user session 层……改了哪一层，就得用对应方式触发重载。不搞清这点，光记命令没用。
