Linux运维中环境变量需统一命名与存放：命名须大写、下划线分隔、前缀区分（SVC_/ENV_/_HOME等），敏感信息禁用明文；配置按系统级（/etc/profile.d/）、用户级（~/.bashrc）、服务级（systemd env.conf）分层存放，全部纳入版本控制并审计。
团队在 Linux 运维中统一环境变量命名与配置存放，核心是避免冲突、提升可维护性、保障多用户/多环境一致性。不需要复杂流程，关键在明确规则并落实到日常操作。
命名规范：大小写敏感 + 语义清晰 + 前缀区分
所有自定义变量必须大写，用下划线分隔单词，禁止中英文混用或特殊符号；关键原则是“见名知义+防冲突”：
-
通用服务类：统一加
SVC_前缀，如SVC_MYSQL_HOME、SVC_REDIS_PORT -
部署环境类：用
ENV_开头，如ENV_CLUSTER_NAME、ENV_DEPLOY_MODE（值限定为prod/staging/dev） -
路径类变量：必须以
_HOME或_BIN结尾，如JAVA_HOME、GRAFANA_BIN，禁止直接暴露/opt/xxx到脚本中 -
敏感信息类（如密钥、token）：一律不设环境变量，改用
systemd的EnvironmentFile=或 HashiCorp Vault 动态注入，严禁出现在任何明文配置文件中
配置存放标准：按作用域分层，禁用硬编码
变量不能散落在任意文件里，必须按生效范围严格归类，且所有修改需走版本控制（如 Git 仓库中的 infra/env-config/ 目录）：
-
系统级全局变量（所有用户共用）：仅允许写入
/etc/profile.d/*.sh，每个服务一个独立文件（如java11.sh、python311.sh），文件内只含export行，不包含逻辑判断或命令执行 -
用户级变量（运维人员专属）：统一存于
~/.bashrc，但仅限个人调试用途；生产环境的运维账号（如ops）须通过 Ansible 模板统一部署/home/ops/.bashrc，禁止手动编辑 -
服务级变量（守护进程专用）：由
systemd管理的服务，变量必须写在/etc/systemd/system/service-name.service.d/env.conf中，格式为Environment="KEY=VALUE"，避免污染 shell 环境 -
禁止行为：不在
/etc/environment中设置依赖变量（如JAVA_HOME不能用于计算PATH），不修改/etc/profile主文件，不向~/.profile写 PATH 追加逻辑
验证与审计机制：每次变更必须可追溯、可回滚
配置不是写完就结束，要建立轻量但有效的检查闭环：
- 新增变量后，必须在目标主机运行
env | grep ^SVC_ | sort和systemctl show service-name --property=Environment双重确认 - 所有
/etc/profile.d/文件需带注释头，注明作者、日期、关联服务版本，例如：# SVC_JDK11 v11.0.22 - added 2026-09-10 by ops-team - CI 流水线中加入检查项：扫描
/etc/profile.d/*.sh是否含echo、if、未引号包裹的路径、重复export定义 - 每月执行一次
diff -u /etc/profile.d/{old,new}/对比，变更记录同步至内部 Wiki 的「环境变量台账」页
不复杂但容易忽略：命名和存放不是技术问题，而是协作契约。只要团队在第一次提交 .sh 文件前对齐这三条，后续维护成本会大幅下降。
