在 Docker 容器中，环境变量是传递配置的核心手段。许多开发者都遇到过这样的困惑：明明在 Dockerfile 里设置了 ENV，运行时却不起作用；或者 docker-compose.yml 里的环境变量被命令行覆盖了。要解决这些问题，关键在于理解 Docker 容器环境变量的配置方式及其优先级。本文将提供清晰的判断路径，并详细展开各种配置方法的细节、取舍和常见误区。
优先级总览：先看运行时，再看定义处
Docker 容器环境变量的优先级从高到低依次为：docker run 命令行中的 -e 或 –env > –env-file 指定的文件 > docker-compose.yml 中的 environment 或 env_file > Dockerfile 中的 ENV 指令。这个顺序意味着，运行时显式指定的值会覆盖镜像构建时设置的默认值。这一原则同样适用于 Kubernetes 等编排平台，其配置思想与 Docker 一脉相承，但具体实现有所不同。
方法一：docker run 命令行直接设置
最直接的方式是在 docker run 命令中使用 -e 或 --env 参数指定环境变量。例如：
docker run -e MY_VAR=value -e ANOTHER_VAR=another nginx:latest
也可以只指定变量名而不赋值，此时 Docker 会从宿主机环境继承同名变量的值：
docker run -e HOST_VAR nginx:latest
这种方式适合临时测试或快速启动，但若变量较多，命令行会显得冗长且不易维护。此外，-e 的优先级最高，它会覆盖 --env-file 和 Dockerfile 中的设置。注意，当使用 -e 且未赋值时，如果宿主机没有该变量，容器内该变量会被设置为空字符串，而非未定义。
方法二：使用 –env-file 文件批量加载
当环境变量数量较多时，可以使用 --env-file 参数从文件中加载。文件格式为每行一个 KEY=VALUE，支持注释（以 # 开头）和空行。例如：
# 创建 env.list 文件
DB_HOST=mysql.example.com
DB_PORT=3306
然后运行：
docker run --env-file ./env.list nginx:latest
与 -e 相比，--env-file 便于批量管理和版本控制。但注意，--env-file 的优先级低于 -e，如果同时使用，-e 中的同名变量会覆盖文件中的值。另外，文件中不能包含引号或转义字符，否则会被原样解析。
方法三：docker-compose 中的 environment 与 env_file
在 docker-compose.yml 中，可以通过 environment 或 env_file 为服务设置环境变量。例如：
services:
web:
image: nginx
environment:
- MODE=production
env_file:
- ./web.env
其中 environment 直接定义变量，env_file 指向外部文件。两者的优先级：environment 中的变量会覆盖 env_file 中的同名变量，但两者都低于 docker run 命令行中 -e 的优先级。当使用 docker-compose up 时，命令行无法直接传递环境变量，但可以通过 docker-compose run -e 实现临时覆盖。
方法四：Dockerfile 中的 ENV 指令
在镜像构建阶段，Dockerfile 中的 ENV 指令用于设置环境变量，这些变量会作为镜像的默认配置。例如：
FROM nginx
ENV NGINX_PORT=8080
这些变量会随镜像保存，并在容器启动时生效。但它们的优先级最低，任何运行时配置（如 -e、--env-file、compose 文件）都会覆盖它们。因此，Dockerfile 中的 ENV 适合定义不常变化的默认值，而将动态配置留给运行时。
优先级冲突时的实际表现与判断路径
当多个配置来源同时存在时，实际生效的值遵循以下判断路径：
- 检查 docker run 命令行：如果使用了
-e或--env，则该值优先。 - 检查 –env-file 文件：如果未使用
-e，但指定了--env-file，则文件中的值生效。 - 检查 docker-compose 配置：如果使用 compose，且未通过命令行覆盖，则
environment优于env_file。 - 检查 Dockerfile 中的 ENV：如果以上均未设置，则使用镜像构建时定义的默认值。
例如，若 Dockerfile 中设置 MODE=development，docker-compose 中设置 MODE=staging，而运行 docker run -e MODE=production，最终容器内 MODE 的值为 production。这种覆盖机制为用户提供了灵活性和可预测性。
常见误区与失败条件
在实际操作中，有几个常见误区容易导致环境变量配置无效：
- 误区一：在 Dockerfile 中使用 ENV 设置变量，但运行时未覆盖，却期望不同值。解决方法是使用
-e或 compose 文件显式设置。 - 误区二：–env-file 文件格式错误。文件中的引号、空格或特殊字符会导致解析失败，应确保每行严格为
KEY=VALUE格式。 - 误区三：在 docker-compose 中同时使用 environment 和 env_file，但未注意优先级。应明确 environment 会覆盖 env_file。
- 误区四：使用
-e但未赋值，且宿主机变量不存在。此时变量会被设为空字符串，可能导致应用报错。
此外，在 Kubernetes 中，环境变量可通过 env 和 envFrom 配置，其优先级和覆盖逻辑与 Docker 类似，但需注意 Kubernetes 的 ConfigMap 和 Secret 的引用方式。这些概念在 Kubernetes 官方文档中有详细说明。
实战建议：如何组织环境变量配置
为了减少混乱，建议遵循以下原则：
- 默认值放在 Dockerfile：将不常变化的默认配置（如应用端口）写入 ENV。
- 环境差异放在运行时：使用
--env-file或 compose 的env_file管理不同环境（开发、测试、生产）的变量。 - 敏感信息使用 Secret：不要将密码等敏感信息直接写入环境变量或文件，应使用 Docker Secret 或 Kubernetes Secret 管理。
- 避免在命令行硬编码：除非是临时调试，否则尽量使用文件或 compose 配置，便于维护和审计。
通过合理利用优先级，您可以实现“镜像不变，配置多变”的灵活部署，这也是容器化应用的最佳实践之一。
参考资料
延伸阅读