容器运行时修改环境变量不生效，因Docker在启动时固化变量；须重建容器才能生效，可通过docker inspect或printenv验证变量是否注入，并注意compose中environment、env_file与宿主机变量的覆盖优先级。
容器运行中修改环境变量本身不会生效——这不是配置问题，而是docker的设计机制决定的。环境变量在容器启动时注入并固化，进程启动后无法动态更新。所谓“running状态下修改不生效”，本质是误以为能热更新，实际必须重建容器才能让新变量落地。
确认变量是否真正传入容器
别急着改配置，先验证当前容器里到底有没有你设的变量：
- 执行 docker inspect ，在
Config.Env字段里直接查看已注入的环境变量列表 - 或进入容器运行 printenv | grep YOUR_VAR，确认变量是否存在、拼写是否大小写一致
- 若变量根本没出现，说明问题出在传递环节，不是应用读取逻辑
区分不同来源的变量优先级
Docker Compose 中变量可能来自多个地方，它们按固定顺序覆盖：
- 最高优先级：compose 文件中
environment:下显式写的值（会覆盖其他所有来源） - 其次：通过
env_file:加载的文件（如.env或java_run.env） - 最低：宿主机 shell 当前已导出的同名变量（容易被忽略但常造成干扰）
例如你在 .env 里写了 DB_HOST=192.168.1.10，但终端里提前执行了 export DB_HOST=127.0.0.1，那么最终进容器的就是后者。
确保镜像引用合法，避免重建失败
常见陷阱：docker-compose.yml 中镜像写成 image: myapp:${IMAGE_TAG}，但启动时没提供 IMAGE_TAG 值。
- Docker 会把空变量解析为
myapp:，这是非法镜像名，导致up -d实际静默失败或跳过重建 - IMAGE_TAG=v260507 docker-compose up -d --force-recreate
检查 .env 文件格式与位置
Compose 默认只加载同目录下的 .env 文件，且格式极其严格：
- 文件名必须是
.env（不能是env、docker.env等） - 等号两侧**不能有空格**：
KEY=value✅，KEY = value❌ - 注释行必须以
#开头，且不能跟在值后面（KEY=value # comment不被识别） - 若用自定义文件名（如
java_run.env），必须在 service 中用env_file:明确声明
