docker容器启动后环境变量不可动态更新，env和-e注入的变量仅作为启动参数，用于引导应用连接配置中心；真正的运行时配置需由应用主动从nacos等中心拉取并热刷新，敏感凭证应通过secrets或文件挂载方式安全传递。
docker 容器本身不支持运行时动态更新环境变量——一旦容器启动，env 和 -e 注入的变量就固化在进程环境中，无法被外部修改。所以“配合配置中心动态更新”不是靠 docker 原生机制实现的，而是通过应用层主动拉取 + 重启/热重载机制来达成效果。
核心思路：环境变量只做启动引导，不承担运行时配置
环境变量在容器中应定位为「启动参数」：告诉应用去哪连配置中心、用什么凭证、加载哪个命名空间。真正的配置内容由应用自己从外部中心（如 Nacos、Apollo、Consul、etcd 或 HashiCorp Vault）实时获取并监听变更。
-
不要把数据库地址、超时时间等业务配置写死在
ENV里 —— 这些应由应用从配置中心读取 -
环境变量只保留「连接配置中心所需的最小信息」：例如
CONFIG_CENTER_URL、CONFIG_NAMESPACE、CONFIG_TOKEN - 应用需集成对应 SDK（如 Spring Cloud Alibaba Nacos Config、Apollo Client），并启用监听能力
典型配合方式示例
以 Spring Boot 应用接入 Nacos 为例：
- 容器启动时传入：
docker run -e CONFIG_SERVER_URL=http://nacos:8848 -e CONFIG_GROUP=prod -e APP_NAME=user-service ... - 应用启动后，自动连接
CONFIG_SERVER_URL，订阅APP_NAME在CONFIG_GROUP下的配置项 - 当 Nacos 中的
user-service.yaml被修改，应用收到事件，刷新@ConfigurationProperties或@Value绑定的值 - 无需重启容器，配置即刻生效（前提是应用代码支持热刷新）
敏感配置的安全衔接
若配置中心访问凭证（如 Token、AK/SK）不能明文暴露在环境变量中，可结合 Docker Secrets（Swarm）或外部注入方案：
- 生产环境用
docker stack deploy --with-registry-auth+secrets挂载密钥文件，应用从文件读取再构造认证头 - Kubernetes 场景下，用
Secret对象挂载到容器内，环境变量仅指向该文件路径（如SECRET_PATH=/run/secrets/nacos_token） - 避免把
CONFIG_TOKEN=xxx直接写进docker-compose.yml或.env
需要规避的误区
- 试图用
docker exec -it container bash -c "export NEW_VAR=value"修改环境变量——只影响当前 shell，不影响主进程，也不持久 - 依赖
ENV变量做条件判断后生成配置文件——这属于构建期静态行为，无法响应运行时变化 - 把配置中心当成“高级环境变量”，期望 Docker 自动同步——Docker 没有监听和注入能力，必须由应用主动对接
