容器启动后无法真正修改已注入的环境变量，因其在进程启动时已写入内存；可行方案按推荐度排序为：①临时shell覆盖（仅调试）；②重启容器并传入新变量（生产首选）；③对接配置中心实现热更新（微服务适用）。
容器启动后，无法真正“修改”已注入的环境变量——因为环境变量在进程启动时就被写入其内存空间，后续对/proc/[pid]/environ的修改仅限于当前 shell 会话，且不会影响已运行的主进程（如 nginx、java、node 等）。
但你可以通过以下三种实际可行的方式，达到“动态生效”的效果，按推荐程度排序：
直接进入容器临时覆盖（仅限调试）
适用于快速验证或单次操作，不持久、不生效于主进程：
- 进入容器：
docker exec -it /bin/sh - 在当前 shell 中设置新变量：
export DB_HOST=192.168.2.100 - 此变量只对当前 shell 及其子进程有效，重启服务或新开终端即失效
- 若想让主进程重读变量，需手动重启它（例如
kill -HUP 1或supervisorctl restart app），前提是程序支持热重载
重启容器并传入新变量（最常用、可靠）
这是生产环境中唯一保证生效的标准做法：
- 停止旧容器：
docker stop - 用新环境变量重新运行：
docker run -d \ --name my-app \ -e DB_HOST=192.168.2.100 \ -e LOG_LEVEL=warn \ my-app:latest
- 或使用
--env-file加载更新后的.env文件 - 优点：配置清晰、可审计、与 CI/CD 兼容；缺点：有秒级中断
用外部配置中心实现运行时热更新（适合微服务场景）
不依赖重启，而是让应用主动监听变更（如 Nacos、Apollo、Consul）：
- 容器启动时从 Nacos 拉取
DB_HOST等配置，并写入本地文件或内存 - 应用集成 Nacos SDK，监听配置变化，触发连接池重建、日志级别切换等动作
- 环境变量仅用于传递 Nacos 地址和命名空间（如
NACOS_SERVER_ADDR=172.17.0.1:8848），本身不存业务参数 - 实际案例中，配置变更后 1–3 秒内生效，零停机
注意：docker update 命令不能修改环境变量——它只支持资源限制、重启策略、网络等少数运行时参数，环境变量不在其支持范围内。
