docker镜像瘦身分三类场景：构建时用buildx多阶段+压缩参数、导出时管道压缩（gzip/xz）、运行后用slimtoolkit动态裁剪，三者按需组合。
直接用 Docker 镜像压缩工具，核心就三类场景：构建时瘦身、导出时压缩、运行后精简。选哪个取决于你处在哪个环节——是还在写 Dockerfile，还是已经打好镜像要传给同事，又或者镜像跑起来才发现太臃肿。
构建阶段用 Buildx + 多阶段
这是最推荐的源头减重方式，适合开发阶段优化。关键不是“压缩”，而是“不带多余东西进镜像”。
- 用两个 FROM：第一阶段装编译器（比如 golang:1.21），只干活不打包；第二阶段用 alpine 或 distroless，只 COPY 编译好的二进制文件
- 加 --platform linux/amd64,linux/arm64 让 Buildx 自动做多架构兼容和层合并
- 启用 zstd 压缩输出：docker buildx build --output type=image,push=false,compression=zstd -t myapp .
- 避免把整个代码目录 COPY 进去，用 .dockerignore 排除 node_modules、test、docs 等无关内容
导出镜像时用管道压缩
适合已有镜像要离线传输、备份或上传到内网 registry 的场景。不生成大 tar 文件，边保存边压。
- 日常用 gzip 最平衡：docker save myapp:latest | gzip > myapp.tar.gz
- 追求极致体积且不急着压，用 xz：docker save myapp:latest | xz -z -9 --threads=0 > myapp.tar.xz
- 加载时别解压再 load，直接管道：zcat myapp.tar.gz | docker load 或 xz -d -c myapp.tar.xz | docker load
运行后用 SlimToolkit 动态裁剪
适合无法改 Dockerfile 的存量镜像，比如第三方官方镜像、历史遗留服务。它会实际跑一遍容器，只保留真实用到的文件和库。
- 安装后执行：slim build --http-probe=true myapp:latest（自动探活并监控）
- 它会启一个临时容器，记录加载了哪些 .so、读了哪些配置、连了哪些端口，然后打包成 scratch 或极小 base 镜像
- 常见效果：500MB 的 Python 镜像 → 压到 20–30MB；Node.js 镜像从 1GB+ → 60MB 左右
- 注意：应用得能正常启动并完成典型请求路径，否则监控不全，可能删掉必要依赖
不复杂但容易忽略：Buildx 是构建时控制体积的主力，管道压缩是交付时节省带宽的常规操作，SlimToolkit 是兜底方案——三者不是互斥，而是按需组合使用。
