Linux 环境变量管理：export 与配置文件层次

发布时间:2025-11-02 14:13

## 概念 环境变量是进程运行时的一组键值，shell 借它传递路径、语言与认证信息等上下文。同一个变量在不同层次有不同作用范围：直接写 VAR=value 只对当前 shell 生效，export 之后才会被后续启动的子进程继承；写进配置文件才谈得上跨会话持久。很多配置不生效的问题，根源都在这层继承关系没有理清楚，配置的人以为写了就全局可见，实际生效范围远比想象的小。 ## 原理：配置文件的加载顺序 登录 shell 依次读取 /etc/profile 与其下的 profile.d 片段，再到用户的 .bash_profile 或 .profile；非登录的交互 shell 只读 /etc/bash.bashrc 与 ~/.bashrc。常见发行版会在 .bash_profile 里 source 一次 .bashrc，把两条链路接起来。而 systemd 管理的服务进程完全不经过这些文件，它只认 unit 文件里 Environment 与 EnvironmentFile 指定的内容。这就是在终端里手动 source 过、服务仍然读不到变量的原因：配置写错了层，终端会话与服务进程各拿各的环境。 ## 最小实操 把个人自定义变量放进 ~/.bashrc 末尾，保持一处维护。 ``` export JAVA_HOME=/opt/jdk export PATH=$JAVA_HOME/bin:$PATH ``` 保存后执行 source ~/.bashrc 立即生效，新开的会话自动读取。想确认变量有没有按预期继承，可以起一个子进程打印看看。服务进程需要的变量则写进独立文件，交给 systemd 加载。 ``` [Service] EnvironmentFile=/etc/myapp.env ``` 环境文件里一行一个键值，不需要 export 关键字，修改后执行 systemctl daemon-reload 再重启服务。把服务环境与会话环境拆成两个文件分开维护，边界清楚，排查时也省得互相翻找：终端问题查 bashrc，服务问题查 EnvironmentFile，两条线互不干扰。 ## 常见错误 一是在命令行手动 export 就以为永久生效，重连后全部丢失；二是把变量写进 .bash_profile，却在非登录 shell 里使用；三是在 unit 文件里写 shell 语法，导致服务启动失败；四是忘了 cron 与 systemd 的环境极其精简，PATH 往往只有几条系统目录，脚本里用到的非标准路径命令要写绝对路径。排查时用 printenv 逐项核对，用 systemctl show -p Environment 服务名 确认服务实际拿到的内容，两边对上才算配置到位。顺云云服务器执行重装系统后，磁盘里的自定义配置会一并清空，迁移或重建前记得把变量文件导出备份一份。