ENV 设置的环境变量会持久化到镜像层并自动生效于后续 RUN 和容器运行时；但可能因运行时覆盖、多阶段不传递或敏感信息泄露而“看似失效”，需注意作用域与安全实践。

在 Docker 镜像制作中，ENV 指令设置的环境变量默认会持久化到镜像层中，容器启动后自动生效，无需额外操作。但实际使用中容易因覆盖、作用域或运行时干扰导致“看似没生效”，关键在于理解 ENV 的写入时机和生效边界。

ENV 写入镜像层，对所有后续 RUN 和容器运行时都有效

ENV 在构建阶段执行，其值被直接写入镜像的配置元数据（config.json），不是临时 shell 变量。这意味着：

• 后续所有 RUN 指令可直接引用该变量（如 RUN echo $MY_PATH）
• 容器启动后，docker run 启动的进程（包括 entrypoint/shell/cmd）默认继承这些变量
• 即使覆盖基础镜像中的同名 ENV，新值也会完全取代旧值（Docker 不做合并）

避免被启动命令或 shell 初始化脚本意外覆盖

常见失效场景是容器运行时被 entrypoint 或 shell rc 文件重置。例如：

• 若 ENTRYPOINT ["sh", "-c", "export MY_VAR=override; exec \"$@\"", "--"]，它会在运行时覆盖构建时的 ENV
• Alpine 等镜像中，/etc/profile 或 ~/.profile 若有同名 export，可能覆盖镜像 ENV（尤其用 bash 替代 sh 时）
• 使用 docker run -e MY_VAR=xxx 会优先级高于镜像 ENV，属正常行为，不是“未持久化”

验证方式：启动容器后执行 printenv | grep MY_VAR 或 env | grep MY_VAR，确认是否出现在输出中。

敏感信息勿用 ENV，优先考虑 ARG + 构建时注入

ENV 值会保留在镜像历史和镜像配置中，docker history 或 docker inspect 可直接查看，不适用于密码、token 等敏感数据：

• 用 ARG 定义构建参数，在 docker build --build-arg 传入，仅在构建期存在
• 运行时敏感配置建议通过 docker run --secret、挂载文件或外部配置中心注入
• 若必须用 ENV（如非敏感配置项），确保基础镜像不带调试工具（如 curl、cat），降低泄露风险

多阶段构建中 ENV 不跨阶段自动传递

每个构建阶段是独立上下文，前一阶段的 ENV 不会自动带入下一阶段：

• 若需复用，可在第二阶段显式重新声明：ENV MY_VAR=${MY_VAR}（前提是第一阶段已用 ARG/ENV 定义且未被覆盖）
• 更安全做法是将配置写入中间文件（如 RUN echo "MY_VAR=value" > /tmp/env.conf），再 COPY 到目标阶段并 source
• 注意：COPY 不会自动解析 ENV，COPY $SRC_DIR /app 中的 $SRC_DIR 必须已在当前阶段定义为 ENV 或 ARG