Dockerfile 同一条 ENV 引用新变量，结果却是旧值

Dockerfile 在同一条 ENV 里先设置目录，再用它组成另一个变量，构建没有报错，最终路径却仍指向旧目录：

ENV APP_ROOT=/srv/old
ENV APP_ROOT=/srv/app APP_DATA=${APP_ROOT}/data

这里最终 APP_ROOT 是 /srv/app，APP_DATA 却是 /srv/old/data。如果此前根本没有定义被引用变量，组合路径中还可能缺少预期的目录部分。

这是 Dockerfile 构建器处理 ENV 的展开规则：同一条指令中的替换使用处理该指令前的变量值。前面写下的新赋值，要到后续指令才参与替换，不会按从左到右的顺序立刻供同一条指令的其他赋值使用。

先看逻辑指令，而不是文本行数

下面虽然写成了两行，反斜杠把它们连接成的仍是一条 ENV：

ENV APP_ROOT=/srv/app \
    APP_DATA=${APP_ROOT}/data

给 ${APP_ROOT} 加引号、调整花括号，或把参数移到下一行，都没有改变展开的时机。检查最终阶段之前已有的 ENV，包括从父阶段或基础镜像继承的值，就能解释为什么结果恰好取到了某个旧路径。

这里不是 ARG 没有在阶段内声明，也不是程序运行时忘了调用 Shell。应先确定错误值已经写进镜像环境，避免只改容器启动命令。

拆开有依赖关系的 ENV

让第二个变量依赖第一条已完成的设置：

# syntax=docker/dockerfile:1
FROM alpine:3.22

ENV APP_ROOT=/srv/app
ENV APP_DATA=${APP_ROOT}/data

第二条执行时，APP_ROOT 已经是 /srv/app，因此 APP_DATA 得到 /srv/app/data。这份最小 Dockerfile 只用于核对环境展开，不创建目录，也不安装应用；设置路径变量本身不意味着对应目录存在。

互不依赖的常量仍可放在同一条 ENV 中。需要拆开的，是有先后依赖的赋值。不要为了追求更少的指令，把有依赖的两条重新合并。

在独立测试镜像里核对最终值

在只放置上面 Dockerfile 的测试目录中构建，并检查这两个非敏感变量：

docker build -t env-dependency-check:review .
docker run --rm --entrypoint /bin/sh env-dependency-check:review \
  -c 'printf "APP_ROOT=%s\nAPP_DATA=%s\n" "$APP_ROOT" "$APP_DATA"'

按该配置，两个值应分别是 /srv/app 和 /srv/app/data。这是示例的预期结果，不需要通过打印生产镜像的整份环境来判断，更不要把令牌、密码等值写入构建日志。

如果实际项目的值仍不正确，继续检查后续是否有另一条 ENV 覆盖、构建的目标阶段是否正确，以及容器启动配置是否又传入了同名变量。不要用正在运行的旧容器代替对新镜像的核对。

把修复改成 RUN export APP_ROOT=... 不等价。那只是该 RUN 启动的 Shell 环境修改，不会为后续指令或最终容器保存同样的 ENV 设置。

运行时覆盖不会重新计算关联变量

镜像中的 APP_DATA 已经是展开后的字符串。启动时只用 --env APP_ROOT=/opt/app 覆盖第一个变量，不会让第二个自动变成 /opt/app/data。

如果目录确实需要随部署变化，可以在部署配置中明确传入两个一致的值，或者由经过审核的启动程序根据运行时配置计算派生路径。不要把需要运行时求值的关系误当成镜像里保存着的表达式。

修复只改 Dockerfile 时，回退可以恢复原文件并部署原镜像版本；新旧镜像切换不会替你移动已有数据目录。涉及挂载和应用路径的项目，应先核对路径变化是否指向同一份数据，避免把变量修正误变成一次未计划的数据迁移。