Docker容器运行时无法动态更新环境变量，因Linux进程模型限制；可行方案包括启动时传参（-e/--env-file）、Compose环境文件、镜像内ENTRYPOINT加载挂载配置、应用监听文件/配置中心变更、使用Secrets/Vault管理敏感信息，以及必要时优雅重启。
运行中的 Docker 容器无法真正“动态更新”环境变量——这是 Linux 进程模型决定的硬性限制，不是 Docker 的设计缺陷。环境变量在容器启动时由 execve() 一次性加载进 PID 1 进程的内存空间，内核将其锁定为只读。任何试图修改 /proc/1/environ、用 docker exec -e 或 docker update --env 的操作，都不会影响主进程及其子进程的运行时环境。
启动前就该规划好变量来源
真正可行的“动态感”，来自启动阶段的灵活配置机制，而非运行中修改：
-
docker run -e 和 --env-file：每次启动容器时传入新值，适合 CI/CD 流水线或脚本化部署；支持从文件读取（
--env-file .env.prod），避免命令行暴露敏感信息 -
Docker Compose + .env 文件：在
docker-compose.yml中引用${DB_HOST}，配合本地.env控制不同环境变量；修改后只需docker compose up --force-recreate -
镜像内嵌配置逻辑：在 ENTRYPOINT 脚本中检查外部挂载的配置文件（如
/config/app.env），用set -a; source /config/app.env; set +a加载并exec "$@"启动应用——变量虽未“热更新”，但应用可主动重读
需要实时变更？靠应用自身配合
如果业务逻辑确实要求运行时响应配置变化（比如切换日志级别、启用灰度开关），不能依赖环境变量“变”，而要让应用具备感知能力：
- 挂载一个 configmap 或 volume（如
/etc/app/config.yaml），应用监听该文件 inotify 事件，触发 reload - 对接配置中心（如 Consul、Nacos、etcd），应用定期轮询或订阅变更通知
- 通过信号（如
SIGHUP）通知应用重载环境相关配置——这需要应用代码支持，不是容器层能解决的
敏感变量必须用 secrets 或 vault
密码、token 等绝不能写死在 docker run -e 或 Dockerfile 中：
- Docker Swarm 模式下用
docker secret create，容器内自动挂载为文件（/run/secrets/db_password），比环境变量更安全 - Kubernetes 场景统一走
Secret对象，配合 volume mount 或 envFrom - 自建服务可用 HashiCorp Vault，应用启动时按需拉取，避免长期驻留内存
重启是最直接、最可靠的方式
当变量确实需要变更且应用不支持热重载时，优雅重启仍是标准做法：
- 使用
docker stop+docker run新实例，配合反向代理实现零中断（如 Nginx 健康检查 + upstream 切换） - Docker Compose 下执行
docker compose up --detach --force-recreate，自动完成旧容器停止与新容器启动 - 生产环境建议配合健康检查探针（liveness/readiness），确保新实例就绪后再切断流量
