判断增长发生在哪个构建器
同一个项目反复修改依赖、切换分支和构建不同目标以后，构建缓存可能持续增长。即使最终镜像很小，中间构建记录也可能保留很多内容。排查时先确认当前 Docker 上下文，再列出 Buildx 构建器，记录名称、驱动和节点。默认构建器、自建的容器驱动构建器以及远程构建器并不共享同一个完整的缓存视图。不能根据电脑上某个目录变大，就推定所有缓存都由默认引擎产生；也不能把清理远程节点获得的回收量记到本机系统盘上。
对选定构建器执行 docker buildx du，观察记录是否仍在使用、是否与镜像共享，以及最近使用情况。把这份结果和当前构建任务一起看，才能区分长期不用的分支缓存与正在服务发布的缓存。检查时不要并行启动新的构建，否则清理前后的数字容易受到新增记录干扰。这里也不需要暂停整个业务站点：缓存属于构建流程，运行中的应用是否受影响，应根据它和构建环境的关系判断。本文讨论普通开发构建器的管理，不把相同参数直接推广到共享的生产构建集群。
缓存记录不等于最终镜像
多阶段构建可以把编译工具留在前面的阶段，只把运行制品复制到最终镜像。最终镜像因此能够比较精简，但为了复用前面阶段，构建器仍可能保存编译依赖、源码上下文和中间结果。检查缓存时，不要把所有中间内容都视为构建文件写错。需要判断的是复用价值与可用磁盘之间的平衡：经常构建的依赖阶段值得保留，已经结束的实验分支可以逐渐淘汰，而每次都变化的大型上下文则需要回到输入范围进行优化。
缓存挂载还具有另一种生命周期。例如包管理器下载缓存会让后续安装减少重复下载，但它不会因为最终镜像没有包含下载目录就自动消失。项目如果配置了多个目标或不同平台，可能产生多套记录。用量检查应保持相同的构建器和平台背景，避免只比较最终镜像标签。对于可复现性要求较高的项目，缓存只能加速已有的确定性流程，不能充当唯一的依赖来源。依赖版本和镜像摘要仍应在项目配置中明确，否则一次清理可能暴露此前被缓存掩盖的构建不稳定。
从时间条件开始执行一次清理
构建缓存的 prune 可以使用最近使用时间等条件缩小处理范围。示例中的 until=168h 表达保留最近一段时间使用过的记录，它和镜像按创建时间筛选的含义不能混为一谈。执行前先阅读当前版本的命令帮助，明确构建器名称，保留交互确认，并说明下一次构建可能需要重新下载依赖。对于只剩很少可用空间的机器，清理应先选择可以重建的旧记录；不要在同一条命令中顺便处理业务数据卷。
清理不是查询预览。不能把带着强制确认参数的 prune 当作查看候选对象的命令，也不能承诺它会恰好释放某个指定容量。当前版本的 Buildx 提供缓存占用上限、最低可用空间和保留空间等选项，但它们受到实际可删除记录和共享引用的限制。操作结束后应再次读取缓存用量与宿主机空间，核对退出状态。如果仍没有足够空间，继续查找正在使用的记录、镜像共享层和其他构建器；不应立刻把筛选条件放宽到所有存储对象。
为日常增长设置预算
一次清理只能处理当前积累，持续增长需要垃圾回收策略。默认 Docker 驱动的构建器与自建 BuildKit 构建器使用的配置入口不同。前者通常从引擎配置中设置 builder.gc，后者使用对应的 BuildKit 配置文件。先核对驱动，再修改正确的配置，否则配置文件看起来已经保存，实际工作的构建器却完全没有读取。修改前保留现有文件，并将新增字段合并进去，避免覆盖网络、镜像仓库或其他已经生效的设置。
预算应来自机器的工作负载。为操作系统、数据库、日志、备份和临时构建保留空间以后，剩余部分才适合分给缓存。文中的八千兆字节只是演示配置形式，不是推荐所有机器采用的固定数值。更合理的记录包括缓存增长趋势、主要构建目标、可接受的重新构建成本和磁盘告警阈值。垃圾回收是周期性的过程，不能代替整个磁盘的容量监控；保留空间参数与占用上限之间的优先关系，也应按正在使用的 BuildKit 版本进行核对。
减少无意义的缓存失效
构建文件中，稳定的依赖安装步骤可以放在经常变化的业务源码之前。以 Node 项目为例，先复制包管理器清单与锁文件，再安装依赖，最后复制应用代码，有助于让普通正文修改不影响整个依赖阶段。还需要维护 .dockerignore，排除版本控制目录、本地依赖、构建输出和日志。排除规则应保留真正参与构建的输入；如果把锁文件或生成所需资源误排除，缓存占用减少的同时可能造成构建内容不完整。
构建上下文的范围也值得单独检查。把整个多项目目录作为上下文，可能让一个完全无关的文件变化影响构建输入，并增加传输成本。可以从项目自身目录构建，或明确选择需要的上下文，但不能为了缩小目录就偷偷改变文件的来源约定。大型测试素材与发布素材应区分用途。检查缓存是否按预期命中，需要从构建日志中的具体步骤判断；没有执行对照构建时，只能描述预期机制，不能给出已经提升多少速度或节省多少空间的结论。
验证清理与预算确实生效
验证可以分成三个观察点：同一构建器的缓存用量、一次允许缓存失效的构建，以及后续运行时的垃圾回收行为。第一次构建主要验证依赖仍可获得、锁文件仍有效、最终制品能够启动。第二次构建可以观察未改变输入的步骤是否得到复用。记录命令、版本、输入变更和退出状态即可，不应把一次耗时直接当成可靠的性能指标；网络波动、磁盘状态和其他任务都会影响结果，比较时需要说明这些条件。
修改回收策略以后，还应检查构建器是否确实加载新配置，以及配置是否经过重启或重新创建才生效。不同驱动具有不同的管理方法，不能统一写成重启 Docker 就完成。若共享构建器上存在多个项目，应给使用者说明缓存可能被淘汰，并确认并发构建不会受到错误的清理流程干扰。最终验收不是磁盘数字下降一次，而是构建仍然可重建、缓存预算能够被观察、后续增长有边界，并且业务持久化数据没有被加入处理范围。
何时不适合立即清空缓存
离线开发、受限网络和依赖仓库迁移期间，某些缓存可能是短期内完成构建的必要条件。这时应先准备依赖制品和恢复方案，再决定保留窗口。另一些项目依赖编译产物缓存获得可接受的构建时间，全部清空会造成多人同时重新编译。它们并非永远不能清理，而是需要把重建成本算进维护安排。对共享服务，最好通过统一的预算与回收策略减少临时人工清理，避免每个项目分别执行互相影响的全量操作。
当缓存持续快速增长，即使预算已经设置，也应追查输入是否不断产生新版本、构建器是否被重复创建，以及是否存在无人使用的旧节点。容量管理和构建设计需要同时进行。能够重新生成并不意味着保留毫无价值，缓存的价值在于复用稳定输入；能够被引用也不意味着永远应该保留，引用关系还需要对应实际项目生命周期。把构建器归属、输入设计、单次清理和长期预算连起来，才形成一套可以长期维护的缓存管理方法。
把缓存生命周期写进项目约定
多人共用构建器时，需要说明哪些任务可以依赖缓存加速，以及哪些任务必须在缓存缺失时仍然成功。可以在独立构建节点定期执行无缓存验证，用固定的锁文件和基础镜像确认依赖来源。这个验证应与普通发布任务分开安排，防止同时消耗大量资源。发现只有命中缓存才能成功的步骤，应调查网络权限、遗漏的输入和未声明的工具，而不是把缓存永久保留当作修复。构建可重现以后，清理预算才有可靠的前提。
项目归档时，还可以记录构建器名称、主要目标和必要制品的保存位置。某个团队停止使用一套构建器，并不代表其他项目也已迁移完毕；删除整套节点前，应检查其使用者和最近任务。迁移之后的旧缓存可以按约定保留一个观察窗口，再进行处理。这样，缓存管理能够跟随项目生命周期逐步收敛，既不会无限增长，也不会在紧急释放空间时依靠陌生名称和主观猜测决定删除目标。
实现片段
docker context show
docker buildx ls
docker buildx du --builder default
docker buildx prune --help
# 确认默认构建器及依赖可重建后，交互执行：
# docker buildx prune --builder default --filter 'until=168h'
# Docker 驱动的示例配置应合并到原有 daemon.json：
# { "builder": { "gc": { "enabled": true, "defaultKeepStorage": "8GB" } } }
评论 · 0