Docker 官方自20.10起移除--squash参数，多阶段构建是唯一可靠的安全压缩手段：第一阶段编译、第二阶段仅复制必需产物，确保敏感内容不进入最终镜像。
直接说结论：Docker 官方早已移除 --squash 参数（自 20.10 版本起报 unknown flag: --squash），所谓“Docker 与 Squash 技术配合”不是配置问题，而是概念混淆。真正的安全层压缩，不靠“合并层”，而靠“不带多余东西进最终镜像”。
多阶段构建是唯一可靠的安全压缩手段
它从设计上杜绝敏感内容进入运行时镜像，比任何后置压缩都更干净、可审计、可复现。
- 第一阶段用完整工具链（如
golang:1.22或node:20）编译/打包，可自由安装调试工具、下载依赖、运行测试 - 第二阶段只用极简基础镜像（如
alpine:3.20或distroless/static），仅COPY --from=builder运行必需的二进制或静态资源 - 所有构建中间产物（
/usr/src、node_modules、go/pkg、临时 apt 缓存）根本不会出现在最终镜像中，自然无泄漏风险 - 务必显式指定阶段名（
--from=builder），避免因 Dockerfile 调整导致 COPY 断链
如果必须压层，选 docker-squash 或 oci-squash，但要接受代价
它们能物理合并层，但无法修复设计缺陷——比如误把密钥写进某一层再删掉，该密钥仍残留于历史层中（除非用 --from-layer 精确跳过）。
-
docker-squash需 Docker daemon，支持按层数或 layer ID 合并，适合 CI 中快速瘦身已有镜像 -
oci-squash是离线版，直接操作 tar 包，零依赖、不连 daemon，适合 air-gapped 环境或安全审计前的终态固化 - 两者都无法保留原始元数据（
HEALTHCHECK、ENTRYPOINT、ENV），必须手动补全，否则镜像可能启动失败 - 压缩后务必用
docker history --no-trunc和docker image inspect核对层结构与配置项
安全层压缩的关键不在“合并”，而在“隔离”与“裁剪”
多服务集成镜像尤其要注意服务间污染和权限扩散，不能只盯着体积数字。
- 禁用 root 用户：每个服务用独立非特权用户（
USER 1001），并在FROM镜像中提前创建 - 分离配置与代码：敏感配置（数据库密码、API Key）绝不硬编码进镜像，改用 secrets 或 configmap 挂载
- 基础镜像最小化：优先选
alpine或distroless，避开ubuntu或centos等含大量包管理器和 shell 的镜像 - 清理必须在同一 RUN 行完成：例如
RUN apt-get update && apt-get install -y curl && rm -rf /var/lib/apt/lists/*，分两行则清理动作会单独成层，无效
真正安全的压缩，是让不该存在的东西从一开始就不在镜像里。多阶段构建做到这点，其他方案只是打补丁。
