环境变量五层优先级从低到高为：系统默认值、基础设施注入、ci/cd配置、镜像内定义、运行时覆盖；后写入覆盖先写入，运行时覆盖（如-docker -e或k8s env）具有最高优先级。

环境变量处理多级配置覆盖，核心在于明确“谁定义、谁优先、谁生效”。不同框架和工具虽实现方式各异，但底层逻辑高度一致：按来源层级排序，后写入的值覆盖先写入的值。

明确五层优先级模型

现代应用普遍采用五层环境变量优先级结构，从低到高依次为：

• 系统默认值：操作系统级全局变量，仅作兜底，如 PATH
• 基础设施注入：Terraform/Helm 注入的集群级配置，适用于 K8s 或云平台部署
• CI/CD 配置：GitLab CI、GitHub Actions 中通过 variables 定义的构建时变量
• 镜像内定义：Dockerfile 中 ENV 指令写死的值，打包即固定
• 运行时覆盖：容器启动时用 -e KEY=VALUE 或 Pod spec 的 env 字段显式传入，最高优先级

按工具链分场景落地

不同工具对“覆盖”的理解和执行细节不同，需针对性适配：

Docker Cli

使用 Docker CLI 构建、运行、停止、检查和管理容器与镜像的助手。用于执行容器相关任务。

下载

• Docker Compose：加载顺序为 environment（服务内硬编码）＞ env_file（如 .env.dev）＞ 项目根目录 .env。同名变量以最先解析到的为准，environment 项必然胜出
• ThinkPHP 8.0：不自动识别 .env.*，必须手动调用 Dotenv::createImmutable(...)->load() 加载对应文件；且 APP_ENV 必须是系统级环境变量（非 .env 内定义），否则整个机制失效
• Spring Boot：靠 spring.profiles.active 触发配置文件合并，application.yml（通用）+ application-prod.yml（特有）自动叠加，冲突项以 profile 文件为准
• Flask：推荐类继承结构——Config 基类放通用项，ProductionConfig 等子类只覆盖差异字段，再由 FLASK_CONFIG 环境变量决定加载哪个类

规避常见陷阱

多级覆盖看似简单，实操中高频出错点集中在：

• 编码问题：ThinkPHP 8 要求 .env.* 文件必须为 UTF-8 无 BOM，否则静默失败
• 变量未透传：Apache/Nginx 默认不向 PHP 进程传递自定义环境变量，需在配置中显式 PassEnv APP_ENV
• 缓存未清理：ThinkPHP 修改 .env.* 后必须执行 php think optimize:config，否则旧缓存仍生效
• 覆盖误判：Docker Compose 的 env_file 多文件加载顺序不等于覆盖顺序，实际以最终解析结果为准，建议避免同名变量跨文件重复定义

统一管理建议

不管用哪种技术栈，推荐统一实践：

• 通用配置统一写进 .env，环境特有项拆到 .env.dev、.env.prod 等独立文件
• 敏感信息（密码、密钥）绝不写死在代码或配置文件里，一律通过运行时注入
• 上线前用 env | grep YOUR_PREFIX 或 dump(getenv('KEY')) 实际验证最终生效值
• CI/CD 流水线中，用分支规则自动设置 ENV_STATE=prod 类变量，避免人工切换失误