环境变量注入和配置文件挂载是Docker中最关键的两种配置管理方式：前者用-e或--env-file运行时注入，避免敏感信息硬编码；后者用-v只读挂载配置文件，需注意路径、权限及类型匹配；二者可组合实现高解耦配置。
在 Docker 容器中，环境变量注入和配置文件挂载是两种最常用、也最关键的配置管理方式。选对方法，能兼顾安全性、可维护性和部署灵活性；用错方式，容易导致敏感信息泄露、配置不生效或镜像耦合过重。
环境变量注入：优先用 -e 和 --env-file
运行时通过 docker run 注入环境变量，适合动态值（如数据库地址、密钥前缀）或不同环境差异大的参数。
-
单个变量用
-e KEY=VALUE：适合少量、非敏感变量，例如docker run -e ENV=prod -e PORT=8080 nginx -
批量变量用
--env-file：更安全、更清晰，把变量写在本地文件（如.env.prod），再挂入：docker run --env-file .env.prod nginx
注意：该文件不进入容器，仅用于启动时读取；支持#注释和空行，但不支持变量展开（如$HOME） -
避免在 Dockerfile 中硬编码敏感变量（如
ENV DB_PASSWORD=123），会导致镜像层残留，应一律推迟到运行时注入
配置文件挂载：用 -v 映射外部配置，推荐只读模式
当应用依赖完整配置文件（如 application.yml、nginx.conf、log4j2.xml），直接挂载比环境变量更直观、更符合应用原生习惯。
-
语法为
-v /host/path:/container/path:ro，末尾:ro表示只读，防止容器内误改或攻击者篡改配置 -
路径需绝对路径：宿主机路径必须是绝对路径（如
/opt/myapp/conf/app.yml），相对路径会被视为绑定挂载到当前目录下的某个子目录，易出错 -
注意文件权限与用户匹配：若容器以非 root 用户运行（如
USER 1001），需确保挂载文件对目标 UID 可读；必要时用chown或chmod预处理
组合使用：环境变量驱动配置加载逻辑
高级用法是让配置文件本身“可变”——例如 Spring Boot 应用通过 spring.profiles.active=${SPRING_PROFILES_ACTIVE} 读取不同 profile 的 yml，此时只需注入 SPRING_PROFILES_ACTIVE=prod，再挂载包含 application-prod.yml 的整个 config/ 目录即可。
- 典型命令：
docker run -e SPRING_PROFILES_ACTIVE=prod \<br> -v $(pwd)/config:/app/config:ro \<br> -v $(pwd)/conf/application.yml:/app/application.yml:ro \<br> my-spring-app
- 这样既保持配置文件结构清晰，又通过环境变量控制行为分支，解耦程度高
进阶建议：避免常见坑
实际落地中，几个细节常被忽略，却直接影响稳定性：
-
挂载目录时，宿主机路径不存在会自动创建为空目录，但若目标是文件（如
nginx.conf），而宿主机路径是个同名目录，Docker 会把该目录挂进去，导致容器内看到的是空目录而非文件——务必确认宿主机路径类型匹配 -
环境变量名大小写敏感，且部分语言/框架有约定俗成命名（如 Go 的
HTTP_PORT，Python 的DEBUG），需与应用代码严格一致 -
使用
docker-compose时，environment和env_file字段功能等价于docker run -e和--env-file；volumes字段对应-v，语义更清晰，推荐生产环境统一使用
