Dockerfile最佳实践#

关键实践：

1. 多阶段构建：编译环境和运行环境分离（700MB→<100MB）
2. 利用缓存：不常变的层放前面（依赖先于代码）
3. 减小体积：用 slim/alpine 基础镜像、合并 RUN、清理缓存（BuildKit 下可用 heredoc RUN <<EOF 写多行命令，可读性更好）
4. 安全：不用 root 运行、.dockerignore 排除敏感文件

Dockerfile优化我总结为四个字”分层缓小安”。首先是多阶段构建，把编译环境和运行环境分开——第一阶段用JDK镜像编译出jar包，第二阶段用JRE-slim镜像只装运行时，镜像从700MB缩到不到100MB。其次是利用Docker的层缓存机制，关键是把不常变的层放前面：先COPY pom.xml安装依赖，再COPY源码编译，这样改代码不会重新下载依赖。第三是减小体积，用alpine或slim基础镜像，多个RUN命令合并成一条减少层数，安装完包后清理apt缓存。最后是安全，不用root用户运行容器（USER指令指定非root），用.dockerignore排除.env、.git等敏感文件，避免密钥泄露到镜像里。实际项目中这四点落地后，构建速度提升明显，镜像体积和安全性也大幅改善。

追问方向：

• “多阶段构建的原理是什么？”→ Dockerfile 中用多个 FROM 指令定义多个阶段，最终镜像只包含最后一个阶段的内容；编译阶段用 JDK 全量镜像，运行阶段用 JRE-slim，通过 COPY —from 把产物拷过去
• “Docker 缓存失效的规则？”→ 每层指令内容或其依赖文件发生变化时该层及后续所有层缓存失效；所以把 COPY pom.xml + RUN mvn dependency 放前面，COPY src 放后面，改代码不会重新下载依赖
• “alpine 镜像有什么坑？”→ alpine 用 musl libc 替代 glibc，部分 Java 原生库（如 JNI、gRPC）可能不兼容；生产建议用 debian-slim 或 distroless 镜像更稳定

易错点：

• ❌ 在后一条 RUN 里 rm 掉前面装的东西就能减体积——前一层的文件仍留在镜像里；清理必须和安装写在同一条 RUN（如 apt-get install ... && rm -rf /var/lib/apt/lists/*），或者用多阶段构建只拷产物
• ❌ 用 ARG/ENV 传密钥，或 COPY 进来再删——会留在镜像层 / docker history 里；构建期密钥用 BuildKit 的 RUN --mount=type=secret，运行期用 K8s Secret 注入
• ❌ 以为分层顺序是唯一的缓存手段——BuildKit 还支持 RUN --mount=type=cache,target=/root/.m2 把 Maven 本地仓库做成跨构建缓存，pom 变了也不用全量重新下载