环境变量管理核心是规划配置来源、明确加载顺序、隔离敏感信息、适配运行时需求；需按场景选择存放位置（如本地用.env、容器用--env-file、k8s用configmap/secret），严格遵循命令行＞environment＞env_file＞宿主机＞.env的优先级规则，并禁止明文存储密钥类信息。
服务器环境变量管理不是“写代码”，而是规划配置来源、明确加载顺序、隔离敏感信息、适配运行时需求。核心在于让服务启动时能稳定、安全、可复用地拿到它需要的参数，比如数据库地址、密钥、日志级别等。
下面从实操角度分四块讲清楚：
环境变量该放哪儿？按场景选对位置
-
本地开发：用
.env文件（项目根目录），配合dotenv类库自动加载（如 Node.js 的require('dotenv').config()，Python 的python-dotenv） -
容器部署（Docker Compose）：
- 公共非密配置 → 放
.env（自动读取） - 敏感值（如
OPENAI_API_KEY）→ 不进 Git，通过 CI/CD 注入或docker-compose --env-file prod.env up单独指定 - 需要覆盖默认值 → 在
docker-compose.yml中用${VAR:-default}语法，例如- LOG_LEVEL=${LOG_LEVEL:-info}
- 公共非密配置 → 放
-
Kubernetes 生产环境：
- 普通配置 →
ConfigMap挂载为环境变量 - 密钥类 →
Secret对象，以envFrom或valueFrom.secretKeyRef方式注入 - 避免在 Deployment YAML 里硬写
value: xxx
- 普通配置 →
加载顺序必须理清，否则值会被意外覆盖
不同来源的变量有固定优先级（从高到低）：
- 命令行传参（
docker run -e DB_HOST=prod-db ...） -
docker-compose.yml中environment:字段定义的变量 -
env_file:引入的文件（如env_file: .env.prod） - 宿主机已有的环境变量（执行
docker-compose up前export DB_PORT=5433） -
.env文件（仅当未被其他方式覆盖时生效）
⚠️ 注意：.env 不会自动覆盖系统已有变量；而 environment: 中显式写的键，会强制覆盖 .env 和宿主机变量。
敏感信息绝不能明文暴露
- 所有含密码、密钥、Token 的变量，禁止出现在
.env、docker-compose.yml、Git 仓库或镜像层中 - 推荐做法：
- 开发时用占位符（如
DB_PASSWORD=CHANGE_ME）+.env.example提示格式 - 测试/预发环境用 Vault 或 CI 的 secret vault（如 GitHub Secrets、GitLab CI Variables）
- 生产环境统一由运维通过 Secret 管理工具下发，应用只认变量名，不碰值本身
- 开发时用占位符（如
应用层怎么安全读取？别依赖“存在即可用”
- Java（Spring Boot）：用
@Value("${DB_URL:jdbc:h2:mem:test}")带默认值，避免空指针；生产禁用@PropertySource("file:/etc/config/app.properties")这类外部文件路径（权限风险） - Python（Flask/Django）：优先用
os.getenv('REDIS_URL') or 'redis://localhost'，不直接os.environ['REDIS_URL']（会抛 KeyError） - Go：用
cleanenv或viper，支持结构体绑定 + 必填校验（如env-required:"true"） - Node.js：
process.env.PORT || 3000，配合zod或joi做启动前校验
关键逻辑就这些：配置分离是前提，加载顺序是规则，安全边界是底线，应用容错是保障。
