docker run -e用于运行时动态注入环境变量，支持单个（-e KEY=VALUE）、多个（多次使用-e）、继承宿主机变量（-e KEY）及文件加载（--env-file），优先级高于Dockerfile中ENV，适用于多环境部署但需规避敏感信息明文暴露。
通过 docker run 的 -e（或 --env）参数，可以在容器启动时将环境变量注入应用，实现配置的动态化——无需重新构建镜像，就能适配不同环境（如开发、测试、生产）或临时调试需求。
Env参数的基本用法与生效时机
环境变量通过 -e KEY=VALUE 传入，在容器启动的初始阶段注入到容器进程的环境空间中。它对 ENTRYPOINT 和 CMD 启动的主进程及其子进程可见，但不会写入镜像层或持久化存储，属于“一次性运行时配置”。
-
单个变量：
docker run -e DB_HOST=10.0.1.5 myapp -
多个变量：
docker run -e ENV=prod -e LOG_LEVEL=warn myapp -
从宿主机继承：
docker run -e DB_PASSWORD myapp（只传宿主机已定义的DB_PASSWORD） -
从文件批量加载：
docker run --env-file ./config.env myapp（config.env每行KEY=VALUE，空行和以#开头的行会被忽略）
应用如何正确读取这些动态配置
环境变量只有被应用主动读取才起作用。常见语言/框架的典型做法：
-
Node.js：直接访问
process.env.DB_HOST；推荐配合dotenv（仅用于本地开发）或原生process.env读取 -
Python：使用
os.environ.get("DB_HOST")；Django 用os.getenv("DEBUG", "False").lower() == "true"转布尔值 -
Java/Spring Boot：通过
@Value("${db.host:localhost}")或System.getenv("DB_HOST")获取；注意 Spring 默认支持DB_HOST→db.host的自动映射 -
Go：调用
os.Getenv("DB_HOST")；建议封装为配置结构体并做类型转换和默认值兜底
⚠️ 注意：若应用在启动早期（如 init 阶段）就缓存了环境变量值，后续修改该变量（如 exec 进容器再 set）不会影响已运行进程。
与 Dockerfile 中 ENV 的关键区别
Dockerfile 的 ENV KEY=VALUE 是构建期静态设定，会固化进镜像，所有基于该镜像启动的容器都继承它，且可被 docker run -e 覆盖。而 docker run -e 是运行期动态覆盖，优先级更高。
- 镜像中设
ENV LOG_LEVEL=info - 运行时执行
docker run -e LOG_LEVEL=debug myapp→ 容器内实际值为debug - 若运行时未指定，则回退到镜像中定义的
info
这种机制天然支持“镜像一次构建，多环境部署”，是 CI/CD 流水线中解耦配置与代码的核心实践。
安全与生产注意事项
敏感配置（如密码、密钥）不应明文出现在命令行或 --env-file 中，因为可能被 ps、Shell 历史、审计日志捕获。
- 改用
docker run --secret（需启用 BuildKit）或挂载/run/secrets/xxx - 使用
docker-compose.yml的environment+env_file，并确保.env文件不提交到 Git - 避免在脚本中拼接
docker run -e "PASSWORD=$PASS"，应改用--env-file或 secret - 确认应用是否对环境变量做过滤或校验（例如拒绝空值、校验格式），防止因缺失变量导致静默失败
不复杂但容易忽略：动态注入的本质是“让配置流动起来”，关键在运行时传递、应用及时读取、敏感信息隔离三者协同。
