ARG仅在定义阶段有效，多阶段构建中需每阶段显式重声明；ENV则持久化至运行时，跨阶段传递须先ARG再ENV赋值。
环境变量在多阶段构建和编排中传递参数，核心在于分清 ARG（构建时） 和 ENV（运行时） 的职责边界，并明确它们的生命周期与作用域。直接把 ARG 当 ENV 用，或指望它自动跨阶段生效，是常见误区。
多阶段构建中正确传递构建参数
ARG 在每个构建阶段独立存在，不会自动延续到下一阶段。想让参数在多个阶段可用，必须显式重复声明，并通过 ENV 固化为运行时变量：
- 每个阶段开头都需重新写
ARG VAR_NAME，哪怕只是复用默认值 - 在需要使用该值的阶段，用
ENV VAR_NAME=$VAR_NAME转为环境变量，才能被后续 RUN、CMD 或应用读取 - 构建时统一传参：用
docker build --build-arg VAR_NAME=value，所有已声明该 ARG 的阶段都会接收该值 - 避免在 ARG 中硬编码敏感信息（如密码），除非启用 BuildKit 的
--secret机制
运行时环境变量的注入与优先级控制
最终容器启动时的环境变量，由 Dockerfile 的 ENV、docker run -e、docker-compose environment 和 env_file 共同决定，遵循明确的覆盖规则：
minimax-mcp-docker版（适配极空间）
下载
MiniMax 图片理解 + 网络搜索 MCP 工具。适配 Docker 环境（极空间等），支持图片 OCR 识别、图像内容理解、网络搜索。API Key 安全存储在本地 credentials 文件，不暴露在代码中。
- Dockerfile 中的
ENV KEY=VALUE提供默认值，写入镜像层，运行时可见 -
docker run -e KEY=override优先级最高，会覆盖所有其他来源 - docker-compose.yml 中
environment:块次之；env_file:最低，适合基础配置 - 若需动态生成（如从 CI 环境读取），推荐在 entrypoint 脚本中导出变量，再 exec 启动主进程
结合 Kubernetes 的配置传递实践
K8s 不直接解析 Dockerfile 的 ARG/ENV，而是通过 Pod 模板注入运行时变量：
- 用
env:字段直接定义键值对，支持valueFrom:从 ConfigMap 或 Secret 引用 - ConfigMap 可映射整个文件为环境变量（
envFrom:+configMapRef），适合批量配置 - Secret 必须用于密码、token 等敏感数据，且需在容器内以文件或环境变量形式挂载
- 避免在 Deployment 中硬写
env:值，应抽象到 ConfigMap/Secret，实现配置与镜像解耦
一个典型 Java 应用的端到端示例
比如要将版本号 APP_VERSION 既用于构建标签，又用于应用日志输出：
- Dockerfile 第一阶段：
ARG APP_VERSION=1.0.0→RUN echo "v$APP_VERSION" > /build/version - 第二阶段：
ARG APP_VERSION→ENV APP_VERSION=$APP_VERSION→COPY --from=builder /build/version /app/ - K8s 部署时：
env: [{name: APP_VERSION, valueFrom: {configMapKeyRef: {name: app-config, key: version}}} ]
