导出环境变量的关键是让子进程继承，不export则变量仅限当前shell；export var=值一步到位最安全，引号避免空格或特殊字符报错；export -p验证是否真正导出，临时设置仅当前会话有效，永久生效需写入配置文件并source或重启会话。
导出环境变量不是“设了就能用”，关键在于让子进程能继承它——不 export，变量就只活在当前 Shell 里，脚本、新终端、bash 子 shell 全都看不见。
export 变量名=值 是最常用也最安全的写法
一步到位，避免先赋值再导出时漏掉 export。Shell 会自动识别等号右侧是否带空格或特殊字符，但加引号更稳妥：
-
export PATH="/usr/local/bin:$PATH"—— 追加路径，必须用双引号包裹，否则$PATH不展开 -
export MY_APP_ENV="production"—— 字符串含空格或符号时，引号不能省 -
export DEBUG=1—— 纯数字或布尔标识，可不加引号，但加了更统一、少歧义
错误示范：export MY_VAR=hello world 会报错：bash: export: `world': not a valid identifier，因为没引号，Shell 把 world 当作第二个参数。
先赋值再 export 容易漏掉，且作用域易混淆
这种两步写法常见于调试或条件分支中，但风险明确：
-
CONFIG_DIR="/opt/myapp/conf"→ 局部变量，仅当前 Shell 可见 -
export CONFIG_DIR→ 此时才变成环境变量 - 若中间执行了
bash进入子 shell，再回来，CONFIG_DIR还在，但没导出过，子 shell 依然读不到 - 若忘记第二步，后续所有依赖它的脚本都会静默失败（比如找不到配置目录）
典型陷阱：在 .bashrc 里写了 MY_LOG_LEVEL=debug 却没 export，结果 systemd 服务或后台脚本始终用默认级别。
export -p 查看哪些变量真被导出了
export 命令不带参数时输出的是 declare -x 格式，只显示已导出的变量；而 set 或 env 容易误判：
-
export或export -p→ 只列真正导出的变量（推荐用于验证） -
env→ 输出当前环境变量，但不含未导出的局部变量，也不含函数 -
set→ 列出全部变量 + 函数，但无法区分哪些是导出的（比如看到MY_VAR=foo，但不确定它是否可被子进程继承） -
printenv MY_VAR→ 只查单个变量是否存在且导出，返回空表示没导出或不存在
注意：echo $MY_VAR 成功只说明变量有值，不代表它被导出；必须用 export -p | grep MY_VAR 才能确认是否进入环境表。
临时导出 vs 永久生效：别把 export 写进脚本末尾就以为全局可用
在当前终端执行 export VAR=value，只对当前会话及其后启动的子进程有效；关闭终端即失效。永久生效需落盘：
- 用户级永久：写入
~/.bashrc（交互式 shell）或~/.profile（登录 shell），然后source ~/.bashrc - 系统级永久：写入
/etc/environment（不支持变量展开，只能写死值）或/etc/profile.d/*.sh（支持export语句） - 关键区别：
~/.bashrc中的export对非交互式 shell（如 SSH 执行命令、cron 脚本）默认不加载，这类场景要用~/.profile或显式source
最容易忽略的一点：GUI 应用（如 VS Code、PyCharm）通常不读 ~/.bashrc，它们继承的是桌面环境启动时的环境变量——改完 .bashrc 后必须重启桌面会话或手动在 GUI 终端里 source，否则编辑器里跑的脚本还是看不到新变量。
