环境变量在容器生命周期中无法直接动态修改并立即生效，因其进程环境空间启动后已固定；但可通过启动前注入（-e/--env-file）、应用热重载、信号通知（如sighup）或重启容器等方式等价实现配置变更效果。
环境变量在容器生命周期中无法直接“动态修改并立即生效”，因为容器启动后，其进程的环境变量空间已固定，操作系统不支持运行时批量更新已有进程的环境变量。但可以通过不同层级的策略实现配置变更的效果等价——即让应用感知到新配置、重新加载或重启后使用新值。
容器启动前：用 -e 或 env_file 注入可变值
这是最常用、最可控的方式。环境变量在 docker run 或 docker-compose up 时传入，属于启动上下文的一部分。
-
单次覆盖：用
-e KEY=VALUE覆盖镜像内置或 Dockerfile 中的 ENV 值，例如：docker run -e DB_HOST=prod-db -e LOG_LEVEL=debug nginx:alpine -
批量注入：配合
.env文件和--env-file，适合多变量场景：docker run --env-file .env.production my-app - 注意：这些变量只影响新创建的容器，对已运行容器无效。
容器运行中：应用层主动响应配置变化
如果应用本身支持热重载（如 Spring Boot 的 @ConfigurationProperties(refresh = true)、Node.js 的 chokidar 监听文件），可将配置外挂为文件（如 ConfigMap 挂载卷），再由应用监听文件变更并刷新内部状态。
- 环境变量本身不变，但应用读取的配置源（如
/config/app.yaml）被更新，触发 reload - Kubernetes 中常结合
volumeMount+subPath或immutable: falseConfigMap 实现 - 需应用代码配合，不是容器平台自动完成
容器运行中：信号通知或轻量级重启
不重建容器，但让主进程重新初始化——适用于支持优雅重启的应用。
- 向容器主进程发送
SIGHUP（如 Nginx、OpenResty 默认支持）：docker kill -s HUP <container-id></container-id> - 应用捕获该信号后，重新读取环境变量或配置文件
- 前提是应用逻辑明确支持该机制，否则信号会被忽略或导致异常退出
容器运行中：强制替换+重启（最可靠但有中断）
当以上方式不可行时，最稳妥的做法是终止旧容器、用新环境变量启动新容器。
- Docker 场景：
docker stop old-container && docker run -e NEW_VAR=newvalue ... - Kubernetes 场景：更新 Deployment 的
env或envFrom字段，触发滚动更新
（K8s 会新建 Pod，旧 Pod 被逐步删除） - 优点：语义清晰、100% 生效；缺点：存在短暂服务中断或连接断开
本质上，容器的环境变量是进程启动快照，不是运行时 API。所谓“动态生效”，靠的是应用设计、外部触发与容器编排协同的结果，而不是平台直接改写内存中的 environ。
