镜像体积优化直接决定运行环境的内存与磁盘占用，因镜像层为只读叠加结构，冗余文件（如apt缓存、man手册、/bin/sh）即使未运行也常驻磁盘并增加内存映射开销；选用alpine（5mb）、distroless（2–6mb）或scratch（0mb）基础镜像可削减70%以上底座体积，配合多阶段构建、单run内安装+清理、.dockerignore与dive验证，实现硬绑定级资源精简。
镜像体积优化直接决定运行环境的内存与磁盘占用——不是“间接影响”，而是硬绑定关系。一个 1.2 gb 的镜像拉取后至少占 1.2 gb 磁盘；启动时若基础镜像带完整 libc、shell、包管理器，即使应用只用几 mb 内存，容器初始化开销也会多出上百 mb 常驻内存。关键不在“运行时代码”，而在“镜像里塞了什么”。
选对基础镜像，砍掉 70% 以上冗余
基础镜像决定了运行时环境的最小底座。Ubuntu/Debian 镜像自带大量调试工具、文档、man 手册和默认 shell，这些在生产服务中几乎从不调用，却长期占据磁盘并增加内存映射页表开销。
- alpine:latest（约 5 MB）：基于 musl libc + busybox，无 apt/yum，适合大多数 Go/Python/Node.js 应用；注意部分 C 扩展需重新编译适配 musl
- distroless 镜像（如 gcr.io/distroless/static，2–6 MB）：不含 shell、包管理器、甚至 /bin/sh，仅保留动态链接库或静态二进制依赖；适合已预编译的 Go/Rust 服务
- scratch（0 MB）：纯空镜像；仅适用于完全静态链接、不依赖任何系统库的二进制（如 go build -ldflags '-s -w' -o main ./cmd）
用好多阶段构建，剥离构建环境
构建工具链（Go SDK、JDK、gcc、node_modules）只在编译期需要，但若写进最终镜像，就会永久吃掉磁盘并抬高容器启动时的内存 footprint（例如 JVM 进程会扫描更多类路径、Go runtime 加载更多符号表）。
- 第一阶段用 golang:1.22-alpine 或 openjdk:17-jdk-slim 编译产物
- 第二阶段用 alpine:latest 或 distroless/java17，只 COPY 编译好的二进制或 jar
- 避免 COPY . /app 整个源码目录——.git、logs、test/、vendor/ 都不该进运行镜像
清理缓存与中间文件，别让“删除”变成幻觉
Docker 层是只读叠加的，RUN rm -rf /var/lib/apt/lists/* 单独成层，只是标记“上层删了”，原始文件仍躺在下层里。必须把安装+清理写在同一 RUN 中，才能真正剔除字节。
- apt-get：用 --no-install-recommends + && rm -rf /var/lib/apt/lists/* /usr/share/doc /usr/share/man
- apk（Alpine）：加 --no-cache，避免生成 /var/cache/apk/
- npm/pip：构建阶段用 --production 或 --no-dev，运行阶段不装 devDependencies
- Go 构建：go build -o /app/server ./cmd && rm -rf $GOPATH/pkg $GOPATH/src
用 .dockerignore 和 dive 工具做双重验证
人眼容易漏掉隐藏体积来源。.dockerignore 能防止本地开发文件误入构建上下文；dive 则能穿透分层，告诉你哪一层悄悄藏了 300 MB 的 /usr/src/linux-headers。
- .dockerignore 示例：
- .git
.DS_Store
README.md
node_modules/
tests/
docs/
*.log - 检查命令：
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock wagoodman/dive:latest your-app:latest
