优化Dockerfile需合并RUN指令以减少镜像层数，如将apt-get update、install与rm -rf /var/lib/apt/lists/*写在同一RUN中；启用多阶段构建分离构建与运行环境；选用alpine或-slim等精简基础镜像；并清理中间产物。
合并 RUN 指令，减少冗余层
每条 RUN 指令都会生成一个新镜像层，而每个层都保留文件系统变更（包括临时文件、缓存、包管理器索引等）。即使后续命令删除了这些内容，它们仍存在于历史层中，无法被最终镜像丢弃。
正确做法是把安装、配置、清理操作链式写在一个 RUN 中，用 && 连接，并在末尾立即清除无用文件：
-
错误示范：
RUN apt-get update→RUN apt-get install -y curl→RUN rm -rf /var/lib/apt/lists/*（三层，中间两层残留大量 apt 缓存） -
正确示范：
RUN apt-get update && apt-get install -y curl && rm -rf /var/lib/apt/lists/*（单层，清理动作与安装紧耦合）
同理适用于 yum clean all、npm cache clean --force、go clean -cache -modcache 等场景。
启用多阶段构建，只保留运行时必需内容
这是目前最有效、最通用的瘦身手段。它将构建环境（含编译器、源码、测试工具等）和运行环境彻底分离，最终镜像不包含任何构建产物以外的文件。
典型结构：
-
构建阶段（builder）：用完整镜像（如
golang:1.22、node:20）拉取依赖、编译二进制或打包产物 -
运行阶段（runtime）：用极小基础镜像（如
alpine:3.20或debian:bookworm-slim），仅 COPY 构建好的可执行文件或静态资源
例如 Go 应用：最终镜像可从 1.2GB（含完整 Go 环境）压缩至 8MB（仅一个静态二进制 + ca-certificates）。
选用精简基础镜像，从源头控制体积
基础镜像占最终体积比重常超 50%。优先按以下顺序评估：
- scratch：空镜像，仅适用于静态编译且无需 libc 的程序（如纯 Go 二进制），体积≈0，但调试能力为零
- alpine：基于 musl libc 和 busybox，典型镜像仅 5–7MB；注意兼容性（如某些 C 扩展依赖 glibc）
-
-slim 变体（如
python:3.12-slim、node:20-slim）：基于 Debian，移除了 man、docs、perl 等非运行必需组件，体积比 full 版本小 30–50% - 避免使用
ubuntu:22.04、centos:7等完整发行版镜像，除非有强兼容性要求
清理构建中间产物，避免隐式残留
很多工具会在构建过程中生成隐藏文件、调试符号、文档或测试数据，它们不会被自动清理：
- Go：加
-ldflags="-s -w"去除符号表和调试信息；编译后运行strip ./myapp - Python：用
pip install --no-cache-dir；删除__pycache__和.pyc；考虑用pyinstaller --onefile --strip - Node.js：COPY 时排除
node_modules/.bin、test/、docs/；构建后运行npm prune --production - 通用：检查是否误 COPY 了
.git、.github/、vendor/（若已用 multi-stage）、Dockerfile本身
可在 Dockerfile 中添加验证步骤：RUN du -sh /usr/local/lib* /opt /var/cache 2>/dev/null | sort -hr | head -5，快速定位大目录。
