根本原因是分层机制使旧内容未真正删除；应将大文件操作压缩至单层run，或用多阶段构建隔离中间产物，并选用alpine等轻量基础镜像。
修改底层大文件时，docker 镜像体积容易暴增，根本原因不是“改了文件”，而是分层机制导致“旧内容未真正消失”——写入即固化，删除仅标记。要避免体积膨胀，关键在于不让大文件在中间层残留，必须把下载、解压、修改、清理压缩进**同一层**，或干脆不让它触达最终镜像。
把所有大文件操作压进单条 RUN 指令
只要涉及大文件（如 tar 包、编译产物、依赖缓存），就不能拆成多步 RUN。否则，哪怕下一条指令立刻 rm -rf，那几 GB 的原始包仍完整保留在上一层中，无法被回收。
- ❌ 错误写法（两层，体积翻倍）：
RUN wget https://example.com/app.tar.gz
RUN tar -xzf app.tar.gz && ./build.sh && rm -f app.tar.gz - ✅ 正确写法（一层，无残留）：
RUN wget -O- https://example.com/app.tar.gz | tar -xzf - && ./build.sh && rm -rf app.tar.gz
用多阶段构建彻底隔离中间产物
当大文件是编译工具链、测试套件或调试符号时，最干净的方式是不把它放进最终镜像。多阶段构建让前一阶段只负责生成产物，后一阶段只 COPY 必需的二进制或静态资源。
- 第一阶段用 full-featured 镜像（如 golang:1.25）编译源码
- 第二阶段用 alpine 或 distroless 镜像，只 COPY 编译好的可执行文件
- 中间所有的 .o 文件、/usr/lib/gcc、go/pkg 目录全留在第一阶段，不出现在最终镜像里
提前规划文件生命周期，避免“先写再删”陷阱
Docker 不会因你写了 rm 就释放空间，它只记录“这个路径被删了”。所以必须确保：大文件的生存周期严格限定在单层内，且该层不承担其他职责。
- 不要在安装依赖的 RUN 层里顺手下载一个 500MB 数据集
- 不要在 COPY 应用代码后，用另一次 RUN 解压并覆盖其中某几个大资源文件
- 如果必须修改已有大文件（如 patch 二进制），优先考虑在构建外完成，再 COPY 进来；若必须在内，用 RUN + 原地替换 + 同步清理，不跨层
配合基础镜像瘦身，放大分层优化效果
分层合并解决的是“单层冗余”，而基础镜像决定“起点大小”。Alpine（~5MB）比 Ubuntu（~70MB）少掉的 65MB，会在每一层都复利节省——尤其当你的大文件操作层叠加在轻量基底上时，整体膨胀幅度显著收窄。
- FROM alpine:latest 替代 FROM ubuntu:22.04
- 用 apk add --no-cache 替代 apt-get install && apt-get clean（后者仍留部分缓存）
- distroless 镜像连 shell 都没有，天然杜绝误留调试文件的风险
