记录一下那天晚上的排查过程。Ubuntu 20.04 上 docker compose v2.20，改了 .env 里的 REDIS_HOST 之后 docker compose up -d 提示容器 Running，进容器 env 看到的还是旧地址，应用连的还是老 Redis。
刚开始盯着「变量在 environment 段里写死，优先级高过 env_file」，折腾了半个多小时，排掉了。
这类报错背后常见的原因有几处，逐个排除就行。compose 只在创建容器时注入环境变量，up 发现配置没变就跳过了重建。少数情况下是.env 文件位于 compose 项目目录之外，实际读的是另一个同名文件。
还有一种情况，shell 里 export 过同名变量，compose 插值时被外部值覆盖了。
上来先看容器里真实的变量值
docker compose exec app env | grep -E 'REDIS|MYSQL'然后确认 compose 实际解析到的配置
docker compose config | grep -A3 environment强制重建容器让新变量生效
docker compose up -d --force-recreate app复查变量和连通性
docker compose exec app sh -c 'echo $REDIS_HOST'改完先别撤，确认这几项。docker compose config 输出的值与 .env 一致，容器内 env 显示新地址，应用日志里连上的是新 Redis 并且读写正常。
容易忽略的是，environment 段的优先级高于 env_file 和 .env，找变量时按这个顺序倒着查；改完别只 restart，restart 不会重新注入环境变量。监控比日志更早给出信号，事后回看经常能提前半小时发现异常。