Dive 的 CI 检测通过 .dive-ci 文件对镜像空间效率和浪费量设硬性约束：lowest-efficiency-threshold 低于 0.95、highest-wasted-bytes 超 20MB 或 highest-user-wasted-percent 超 0.20 时自动失败，以暴露分层冗余问题。
如何在 CI 中用 .dive-ci 设置层大小告警
Dive 的 CI 检测不是靠“看报告”，而是靠配置文件触发自动失败——关键就是项目根目录下的 .dive-ci。它不分析单个文件，而是对整个镜像的**空间效率**和**浪费量**做硬性约束。
-
lowest-efficiency-threshold: '0.95'：镜像效率低于 95%（即有效文件占比不足 95%）时，CI 直接报错。这是最核心的阈值，反映冗余是否失控 -
highest-wasted-bytes: '20MB'：某一层或全镜像中被标记为“浪费”的字节数超过 20MB 就失败。比如/var/lib/apt/lists/残留、重复拷贝的node_modules -
highest-user-wasted-percent: '0.20'：用户层（非基础镜像层）中，被判定为“无用但占空间”的文件占比超 20%，说明构建过程没清理干净
为什么不能只看总大小，而要看效率分？
因为 docker images 显示的只是最终体积，完全掩盖了分层污染问题。一个 180MB 的镜像，可能效率只有 62%——意味着近 70MB 是各层叠加产生的重复、缓存、临时文件。Dive 的效率分是按「所有层中真正被最后容器使用的文件总大小 ÷ 镜像解压后总大小」算出来的，比单纯卡 highest-wasted-bytes 更能暴露构建逻辑缺陷。
- 效率 RUN 指令（如先
apt-get install再单独rm -rf /var/lib/apt/lists） - 效率 85–94%：可能用了多阶段构建但中间产物清理不彻底，或 COPY 了太多无关文件
- 效率 ≥ 95%：通常已使用 Alpine/distroless 基础镜像 + 合并清理 +
.dockerignore配合
.dive-ci 阈值设太松或太紧都会出问题
阈值不是越严越好，得匹配团队当前优化水位。设得太松（比如 lowest-efficiency-threshold: '0.80'），等于放行明显低质镜像；设得太紧（如 '0.99'），反而会让 CI 频繁失败，尤其当基础镜像本身效率有限（如某些官方 Python 镜像效率天然卡在 96–97%）。
- 推荐起始值：
lowest-efficiency-threshold: '0.95'、highest-wasted-bytes: '20MB'、highest-user-wasted-percent: '0.20' - Alpine 类镜像通常能轻松过 97%，但基于 Ubuntu 的 Spring Boot 镜像若未多阶段构建，95% 就已是较优结果
- 如果 CI 总失败，先运行
dive your-image:tag本地看报告，确认是真实问题还是阈值不合理
CI 流程里怎么真正跑起来？
光有 .dive-ci 文件没用，必须在 CI 脚本里显式调用 dive 并传参。它默认不输出错误码，得加 --ci 模式才触发阈值校验。
- GitHub Actions 示例：
run: dive --ci --no-color ${{ env.IMAGE_NAME }}:${{ env.IMAGE_TAG }} - GitLab CI 示例：
script: - dive --ci $CI_REGISTRY_IMAGE:$CI_COMMIT_TAG
- 注意：Docker daemon 必须在 CI 环境中可用，且
$IMAGE_NAME必须是已 build 完、存在于本地 daemon 的镜像，不能是远程 registry 地址
Dive 的阈值告警本质是把“镜像质量”变成可测试、可阻断的工程指标，但它的数值意义依赖你是否理解每一层背后发生了什么——比如看到某层突增 50MB，得立刻去查 Dockerfile 对应 RUN 是否漏了清理，而不是只调高 highest-wasted-bytes。
