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
