环境变量五层优先级从低到高为：系统默认值、基础设施注入、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 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类变量，避免人工切换失误
