合并同类run逻辑的核心是将功能一致、依赖连续、无中间产物残留的操作压缩进同一run指令，需满足共享上下文、输出直连消费、无需保留临时文件、失败整体中止四条件，用&&和\实现原子执行，避免层断裂导致的冗余和残留。
合并同类 RUN 逻辑的核心，是把功能一致、依赖连续、无中间产物残留的操作，压缩进同一个 RUN 指令里。这不是简单拼接命令，而是按构建意图归组，避免因层断裂导致的冗余快照和文件残留。
识别“同类逻辑”的关键特征
真正属于同一构建意图的操作，通常满足以下全部条件：
- 共享相同的执行上下文（比如都在 /tmp 下解压、编译、安装）
- 前序步骤的输出直接被后续步骤消费（如下载 tar 包 → 解压 → 编译 → 安装）
- 过程中生成的临时文件（缓存、源码、.o 文件等）不需保留到运行时
- 失败应整体中止，而非留下半成品状态
用 && 和 \ 实现安全合并
单个 RUN 中必须用 && 连接命令，确保任意一步失败整条指令退出；换行用反斜杠 \ 维持可读性，但语义仍是原子操作：
RUN apt-get update && \
apt-get install -y --no-install-recommends nginx && \
rm -rf /var/lib/apt/lists/*
这样只产生一层，且清理与安装严格绑定。若拆成两条 RUN，中间层会固化 /var/lib/apt/lists/，体积多出 10–20MB，还可能因缓存过期导致下次构建失败。
minimax-mcp-docker版（适配极空间）
下载
MiniMax 图片理解 + 网络搜索 MCP 工具。适配 Docker 环境（极空间等），支持图片 OCR 识别、图像内容理解、网络搜索。API Key 安全存储在本地 credentials 文件，不暴露在代码中。
警惕伪“同类”——表面相似但本质割裂
以下情况看似可合并，实则违背构建意图，不应强行塞进同一 RUN：
- 安装系统工具（apt）和复制应用代码（COPY）——二者无依赖关系，且 COPY 应独立缓存
- 构建前端（npm build）和安装后端依赖（pip install）——环境、路径、生命周期不同
- 设置时区和创建非 root 用户——虽都属配置，但涉及不同系统路径与权限模型，分开更清晰可维护
配合 history 验证是否真收敛
构建完成后立即运行：
docker history --no-trunc your-image:tag
重点看三点：
- 是否有多个
层——说明某次 RUN 实际未生成有效内容，可能是空操作或被跳过 - 是否存在单层 >50MB 且命令含 curl / wget / git clone——大概率残留了未清理的源码或下载包
- 理想结构应为：基础镜像层 + 1 层依赖安装（含清理）+ 1 层应用复制 + 1 层启动配置
