docker构建中run指令严格串行执行，所谓“并行”实为合理合并命令以减少层数、提升缓存效率；应在一个run中用&&连接原子操作并清理临时文件，或通过多阶段构建分离编译与运行环境。
RUN 指令本身不能“并行”执行，Docker 构建是严格串行的——每条指令（包括 RUN）按顺序逐层执行，前一层输出作为后一层输入。所谓“并”，实际是指避免无谓拆分、合并逻辑相关命令、减少层数，从而提升缓存效率、减小体积、加快构建速度。
为什么不该把 RUN 拆成多条
每条 RUN 都生成一个新镜像层：
- 增加镜像层数 → 加大体积、拖慢传输和启动
- 破坏缓存链：只要其中任意一条 RUN 改动，它及之后所有层全部失效重跑
- 中间层残留临时文件（如 apt 缓存、编译中间产物），不清理就永久保留在镜像里
怎么合理“合并”RUN 命令
核心原则：一个 RUN 完成一组原子性操作，且末尾清理干净。
- 用
&&连接多个 shell 命令，确保前序失败时后续不执行 - 安装软件后立即清理包管理器缓存（如
/var/lib/apt/lists/*或/var/cache/apk/*） - 用反斜杠
换行，保持可读性
✅ 正确示例（Debian/Ubuntu）：
&& apt-get install -y curl jq wget \
&& curl -sL https://example.com/install.sh | bash \
&& apt-get clean \
&& rm -rf /var/lib/apt/lists/*
更进一步：用多阶段构建“绕开”RUN 膨胀
当 RUN 涉及编译、打包等重量级操作（如 go build、npm build、mvn package），不要让它污染最终运行镜像：
- 在构建阶段（builder）用完整环境执行 RUN 编译
- 在运行阶段（runner）只 COPY 编译产物，用轻量基础镜像 + 极简 RUN（甚至无 RUN）
- 这样，构建阶段的臃肿 RUN 完全不出现在最终镜像里
例如 Go 应用：
# 构建阶段FROM golang:1.21-alpine AS builder
WORKDIR /app
COPY . .
RUN go build -o myapp .
# 运行阶段
FROM alpine:latest
RUN apk --no-cache add ca-certificates
WORKDIR /root
COPY --from=builder /app/myapp .
CMD ["./myapp"]
特殊场景：需要“类并行”的替代方案
若确实存在多个独立、耗时且互不依赖的初始化任务（如下载不同工具、预热多个缓存），可考虑：
- 写成单个 RUN 内部用
&启动后台进程 +wait（需谨慎，容器内 PID 1 限制多） - 更稳妥做法：把这类任务封装进 shell 脚本，COPY 进来再 RUN 执行 —— 仍是一条 RUN，但内部可调度
- 或借助构建器插件（如 BuildKit 的
RUN --mount=type=cache）实现并发缓存访问，而非命令级并行
