ARG仅用于构建阶段，不存入镜像；ENV作用于构建和运行阶段，固化到镜像中。ARG适合传版本号等构建参数，ENV适合配PORT等运行时变量，二者协作实现环境隔离。
用 ARG 接收构建时配置，用 ENV 固化运行时行为，是微服务环境隔离的核心逻辑。关键不在“能不能用”，而在“该在哪个阶段暴露哪类信息”。
ARG 专管构建期变量：只进不出，安全可控
ARG 定义的变量仅存在于 docker build 过程中，不会写入镜像层，也不会出现在最终容器里——这是它和 ENV 最根本的区别。
- 适合传入版本号、分支名、编译开关、基础镜像标签等构建依赖但运行无需知晓的信息
- 支持默认值（如
ARG NODE_VERSION=18），未传参时自动 fallback；若没设默认值又没用--build-arg指定，构建会失败 - 多阶段构建中，每个 stage 都要单独声明所需 ARG，不能跨 stage 继承
- 特殊限制：必须在
FROM前声明才能用于选择基础镜像（例如ARG ALPINE_VERSION→FROM alpine:${ALPINE_VERSION}）
ENV 专管运行时变量：持久存在，应用可读
ENV 设置的变量会固化进镜像，并在容器启动后持续生效，任何进程都能通过 os.getenv() 或 printenv 读取。
- 适合配置
NODE_ENV、PORT、LOG_LEVEL、数据库连接地址等应用运行必需的上下文 - 可在
docker run -e KEY=VALUE时被覆盖，也支持在 docker-compose.yml 的environment字段中重写 - 若值来自 ARG，推荐显式赋值（如
ARG APP_ENV+ENV APP_ENV=${APP_ENV}），避免隐式继承带来的可读性问题
组合使用：构建传参 → 运行生效 → 环境隔离
真正实现微服务多环境解耦，靠的是 ARG 和 ENV 的协作，而不是单用某一个。
-
开发/测试/生产镜像统一构建，差异化启动：用 ARG 接收
ENV_TYPE=prod，再通过 ENV 注入并驱动配置文件复制（如COPY config/${ENV_TYPE}/app.yaml /app/config.yaml） -
敏感信息不落盘但可用：构建时传入
--build-arg DB_PASSWORD=xxx，再用ENV DB_PASSWORD=${DB_PASSWORD}导出——密码不会留在镜像历史里，又能在容器内被应用读取（注意：仍建议生产环境改用 Docker Secrets 或外部 Vault） -
镜像瘦身与调试分离：用
ARG DEBUG=false控制是否安装strace或curl，生产构建跳过安装，调试镜像则启用，底层镜像一致，行为由 ARG 驱动
避坑提醒：常见误用与修复方式
很多环境问题其实源于对作用域理解偏差，不是语法写错，而是阶段用错。
-
错误：把数据库密码直接写成
ENV DB_PASSWORD=xxx→ 密码明文固化进镜像，docker history可见 -
修复：改用
ARG DB_PASSWORD+ENV DB_PASSWORD=${DB_PASSWORD}，构建时注入，不存历史 -
错误：在
FROM后才定义ARG VERSION，却想用它指定基础镜像 → 构建报错 -
修复：把
ARG VERSION移到FROM上方，并确保FROM xxx:${VERSION}写在同一 stage -
错误：以为
ARG能被CMD直接引用 → 实际只有 RUN、COPY 等构建指令能访问，CMD 是运行时指令 - 修复：必须通过 ENV 中转，或改用 shell 形式 CMD 并确保 ENV 已设置
