最稳妥的系统级环境变量设置方式是修改/etc/profile，因其全局生效、支持完整shell语法且在每次登录时自动加载；若需模块化管理，应使用/etc/profile.d/下的.sh脚本；注意systemd服务不读取该文件，须在service单元中显式配置environment或environmentfile。
修改 /etc/profile 是最稳妥的系统级变量方式
系统级变量要对所有用户、所有新 shell 会话生效，/etc/profile 是首选。它在每次登录时由 bash 自动 source，且支持完整 shell 语法（比如条件判断、变量拼接），比 /etc/environment 更灵活。
常见错误是直接往 /etc/environment 里写 export PATH=... —— 这个文件不解析 shell 语法，只接受 KEY=VALUE 格式，且不支持 $PATH 展开，强行写会导致 PATH 被覆盖成字面量。
- 用
sudo vi /etc/profile编辑，在末尾添加类似export JAVA_HOME=/usr/lib/jvm/java-11-openjdk和export PATH=$JAVA_HOME/bin:$PATH - 避免在
/etc/profile中使用单引号包裹含变量的值，例如export PATH='$PATH:/new/bin'会失效——单引号禁用变量展开 - 改完后必须运行
source /etc/profile，否则当前终端看不到效果；新打开的终端会自动加载
/etc/profile.d/ 目录更适合模块化管理
如果你要批量加多个变量（比如部署 Java、Python、Node.js 环境），别全堆进 /etc/profile。CentOS 默认会自动 source /etc/profile.d/*.sh 下所有可执行的 .sh 文件，这是更清晰、更易维护的方式。
例如给所有用户加一个 MY_TOOLS 变量：
- 新建
sudo vi /etc/profile.d/my-tools.sh - 写入内容：
export MY_TOOLS=/opt/mytools和export PATH=$MY_TOOLS/bin:$PATH - 确保文件有执行权限：
sudo chmod +x /etc/profile.d/my-tools.sh - 不用重启或重新登录，
source /etc/profile即可立即生效
注意：文件名必须以 .sh 结尾，且不能包含空格或特殊字符，否则可能被跳过。
CentOS Linux 7.9.2009是传统CentOS Linux 7的最后主要版本，也是很多企业历史服务器中仍可能遇到的系统版本。它以稳定、兼容RHEL 7生态、文档丰富和软件支持广泛著称，曾长期用于Web服务、数据库、虚拟化节点和企业内部业务系统。不过CentOS Linux 7已于2024年6月30日停止维护，现在继续使用会面临安全补丁缺失风险。该版本更适合旧业务迁移、历史环境恢复或离线兼容性测试。
systemd 服务里读不到 /etc/profile 设置的变量
这是最容易被忽略的坑。systemd 启动的服务（比如 nginx、redis）默认不读 /etc/profile，它们的环境是“干净”的，只继承 minimal 系统变量。
如果服务需要某个系统级变量（比如 JAVA_HOME），不能靠改 /etc/profile 解决：
- 要么在 service unit 文件里显式设置：
Environment="JAVA_HOME=/usr/lib/jvm/java-11-openjdk" - 要么用
EnvironmentFile=/etc/sysconfig/myservice指向一个纯 key=value 文件 - 或者启用
systemd-logind的PAMEnvironment，但配置复杂，不推荐
验证方法：启动服务后，进其进程 namespace 查看 cat /proc/$(pidof myservice)/environ | tr '\0' '\n' | grep JAVA_HOME，没输出就说明没加载成功。
修改后如何确认变量范围和生效时机
光靠 echo $VAR 不够。关键要看「谁能看到」和「什么时候看到」：
- 普通用户新开 terminal → 能看到
/etc/profile和/etc/profile.d/*.sh里的变量 - root 用户 su 切换到普通用户 → 不触发 login shell，默认不加载
/etc/profile，除非加-l参数（即su -l username） - ssh 远程登录 → 触发 login shell，会加载
/etc/profile - crond 定时任务 → 完全不加载任何 profile 文件，必须在 crontab 条目里手动
source /etc/profile && your_command
真正麻烦的是那些“半登录”场景：比如 GUI 应用、screen/tmux 新建会话、docker 容器内 shell —— 它们行为不一致，得按实际启动方式单独验证。
