构建任务反复报错 No space left on device，日志却没有直接指出哪个目录满了——这是云效平台上最常见的故障之一。云效构建磁盘空间不足清理，本质上是对工作目录、构建缓存和制品留存三个环节的系统性治理，而不是简单扩容或删除文件。理解三者如何增长，是解决问题的第一步。
一、云效构建磁盘空间不足的原因
1. 工作目录占满磁盘
每个构建任务都会在工作目录下执行源码拉取、依赖安装和编译打包，单次构建可产生数GB的临时文件。多个并发任务共享同一构建机时，工作目录的占用会快速叠加。典型报错出现在“安装依赖”或“打包”阶段，此时 df -h 往往显示使用率已达100%。若构建机没有按任务隔离目录，残留的中间产物还会进一步挤占空间。
2. 构建缓存持续膨胀
依赖包和Docker镜像层缓存是增长最快、占比最大的部分。npm、pip、Maven等包管理器会保留历史版本，docker build 也会积累悬空镜像层，且这些缓存跨任务复用，清理不当会拖慢后续构建。云老大在承接CI节点运维时，通常会把缓存目录挂载到独立数据盘，并配置定期清理脚本——这是避免系统盘被占满的常用手段。
3. 制品留存过多
每次构建产生的制品若不做生命周期限制，会在制品库和构建节点上同步堆积。行业共识是设置保留天数（如30天）或最大版本数，像Nexus、Artifactory等制品库均支持这类策略。云效上的构建节点同样需要评估本地制品残留，否则即使远程制品库有清理策略，本地磁盘仍可能被历史产物拖垮。
二、查看云效构建磁盘占用
云效构建机磁盘被写满，从来不是一瞬间的事。工作目录、依赖缓存和制品留存三块空间各自增长，但构建失败时日志只会抛一句 No space left on device，具体是哪个目录撑爆了，往往要靠人工排查。与其盲目扩容或全量删除，不如先花几分钟做一次系统化测量——这一步能帮你区分“临时积压”和“存量设计问题”，避免后续每隔几天就手工抢救一次。
1. 用命令检查空间
SSH 登录构建机后，第一件事是看整体挂载点用量，而不是直接进某个目录删文件。执行 df -h，关注 /、/var/lib/docker、/root 等挂载点的 Use% 数值。当使用率超过 80% 时，构建任务随时可能因申请不到临时磁盘空间而中断；超过 90% 则基本属于高危急状态，需要马上处理。
整体情况摸清后，再用 du -sh / 逐级定位。比较高效的路径是直接对已知的高频占用目录下手：
du -sh /home/admin/workspace /root/.npm /root/.cache /var/lib/docker 2>/dev/null
这里 /home/admin/workspace 通常对应云效构建机的工作目录根路径，/root/.npm 和 /root/.cache 是 npm/yarn/pip 依赖缓存常见位置，/var/lib/docker 则是 Docker 镜像层与容器层所在目录。如果某个目录轻松超过 10GB，那它就是本次磁盘告警的主要贡献者。
需要注意的是，du 在超大目录上可能执行较慢，建议用 du -sh --max-depth=1 限制扫描深度，或者直接先看上一级目录，再逐层进入。不要一上来就 du -sh /* 扫根目录，既慢又容易卡住构建机。
2. 查看云效构建日志确认瓶颈环节
命令只看物理占用，日志则能告诉你“哪一步写入量最大”。进入云效控制台，找到失败的那次构建记录，重点看“安装依赖”“缓存写入”“打包上传”三个阶段的标准输出。
- 如果错误发生在安装依赖的中段，报
ENOSPC，那问题几乎都出在依赖缓存目录——npm 的.npm、pip 的~/.cache/pip、Maven 的/root/.m2。 - 如果错误发生在 Docker 构建指令执行时，比如
failed to write layer或no space left to apply layer，那占满的是/var/lib/docker，需要关注镜像层缓存和悬空镜像。 - 如果错误发生在最后“上传制品”环节，报磁盘不足，但系统盘使用率并不高，这时要检查构建机是否挂载了独立数据盘，制品暂存默认写在了系统盘的
/tmp下，导致系统盘被临时大文件撑满。
日志不会直接列出每个目录的容量，但它能帮你精确缩小排查范围，避免在错误目录上做无效操作。
3. 定位大文件目录
在明确阶段后，用 find 按时间与大小筛选出真正的“垃圾文件”，而不是看到目录大就整体删除。
一个稳妥的组合是：先按修改时间找临时目录，再按文件大小找异常单文件。
# 找出工作目录下超过3天未被修改的构建目录
find /home/admin/workspace -maxdepth 2 -type d -mtime +3 -exec du -sh {} + 2>/dev/null | sort -rh | head -20
# 找出 /root 下超过200MB的独立文件
find /root -type f -size +200M -exec ls -lh {} + 2>/dev/null | sort -k5 -rh | head -20
第一类命中项通常是可以安全清理的历史任务工作目录；第二类命中项可能是被误放进家目录的构建产物或日志包。确认具体路径后，再执行删除，比“清空整个缓存”更精准。如果这一步发现占用大头是 /var/lib/docker 下的 overlay2 目录，那么常规的 du 定位意义不大，直接用 docker system df -v 查看镜像、容器、卷各自的体积分布会更有效。
整体诊断完成后，你对构建机的存储结构就有了一张明确的“分布图”：哪些是工作目录的临时残留、哪些是依赖缓存的持续膨胀、哪些是制品留存无人清理。接下来第三步的“清理工作”才能有的放矢。这里我们结合云老大在多个企业级 CI 运维中的经验，每次执行清理前都先做以上三步诊断，避免误删正在运行的构建任务导致线上事故。
三、清理工作目录的操作
如果拿“磁盘占用”问题去问做过CI/CD运维的工程师，大多会先扔给你一句“先看看是哪儿满了”——这句话背后藏着一个常见的判断失误：很多人以为清理一次工作目录就能一劳永逸，实际上，构建机磁盘空间的"大头"往往不在工作目录里。
工作目录的定位很明确：它只是每次构建任务运行时的临时落点，存放拉取下来的源码、生成的中间文件、编译产物。它的特点是“生命周期短、单次占用量可控、但碎片化严重”。一个Java项目的target/目录可能轻松超过2GB，前端项目拉下来的node_modules动辄1GB以上，如果构建任务中断或者配置不当，这些文件就会安静地躺在工作目录里，成为磁盘空间的隐形消耗者。
1. 删除构建临时文件：先定位，再动手
云效构建机的工作目录默认按任务组织，目录里除了你的源码，还有各种运行痕迹。要清理临时文件，不建议一股脑rm -rf，先执行du -sh按目录大小排序，再精准删除，这是运维的基本素养。
实践中，构建临时文件主要集中在三个位置：
- 构建输出目录：如
target/、dist/、build/，根据技术栈不同，可能残留上一次构建的完整产物； - 包管理器临时文件：
npm的_cacache、pip的cache、maven的repository，这些是“临时”和“缓存”的跨界类型，删除后影响的是重建速度而非正确性； - 日志与中间态文件：构建过程中产生的调试日志、测试报告、临时脚本，往往是几千个小文件堆积，占用inode。
实际执行时，建议登录构建机（或通过云效的节点管理入口），先执行df -h查看整体使用率，再用du -sh /path/to/workspace确认工作目录的总大小。确认后，用带时间条件的方式删除：
# 工作目录下超过7天未被修改的，一次性清理
find /path/to/workspace -type f -mtime +7 -delete
关键不在于删多少，而在于“不误删正在运行的任务”。如果团队是多人共享构建机，建议和团队成员约定一个“维护窗口”，统一清理。另一个需要警惕的时刻是构建任务刚结束后的短暂空闲期——这时工作目录里的文件还“新鲜”，但往往是历史残留最容易被忽视的时刻。
2. 清理旧版本源码：解决“拉取-覆盖-堆叠”的恶性循环
很多研发团队对“工作目录”有一个误解：以为任务跑完源码就自动消失了。实际上，云效构建机的工作目录默认不自动清理，而大部分构建任务的源码拉取策略是git pull而不是全新git clone——这意味着一个项目的多次构建，会在工作目录里不断累积旧版本源码、切换分支时的残留文件、被删除历史文件。
以典型的中型Java项目为例：源码体积约500MB，每次构建拉取新提交并覆盖旧文件，如果代码仓库里有被删除的大文件，或某个分支的历史变更包含大型静态资源，工作目录在多次构建后会膨胀到数GB。一个真实案例：某团队的后端项目工作目录膨胀到8.7GB，排查后发现是.git/objects目录占了4.2GB——多次git pull累积的松散对象没有被压缩，旧分支的历史提交全部沉淀在工作目录里。
清理旧版本源码时，不建议直接删除整个工作目录（这将导致下一次构建重新全量克隆，构建时间延长30%以上），而是有选择地处理：
# 保留最近2次构建对应的源码，其余删除（按目录名或时间）
ls -dt /path/to/workspace/*/ | tail -n +3 | xargs rm -rf
如果工作目录的命名规则区分了项目和构建ID，那么按构建ID保留最近几份即可。这里需要看你的团队具体怎么配置——清理的逻辑不变，都是“保留近期、删除历史”。
3. 设置自动清理策略：别再靠手动应急
只做一次手动清理，本质上是“还债”，构建机磁盘管理如果没有自动策略，这个债会越滚越大。在云效的构建节点上，设置自动清理有几个可落地的方向：
方案一：构建机系统层面配置定时任务
在构建机上配置crontab，每周低峰期自动执行以下操作：
0 3 * * 1 find /path/to/workspace -type f -mtime +7 -delete
这个策略非常简单，但仍然可能误删其他团队的数据。更稳妥的做法是：先探测、再执行，在删除命令前加入目录名称的匹配规则。
方案二：利用云效的分支清理策略
不少团队忽视了CI平台自身的能力。在云效流水线的“代码源”配置中，可以设置“保留最近N次构建的源码”，或者在触发条件中排除部分分支的构建——例如feature/*分支的构建只保留最新一次版本，避免同一个工作目录被多个分支反复覆盖堆叠。
方案三：结合制品生命周期管理
工作目录里最占空间的往往就是构建产物副本。如果构建产物会上传到云效制品库，那么工作目录里那份“中间产物”的唯一价值就只是为了支持增量构建。这种情况下，建议在制品库中设置保留最近5个版本或30天，同时在构建机的清理脚本中，优先删除工作目录内超过3天未访问的构建产物文件。
综合来看，搭建自动清理策略时最稀缺的不是命令行技能，而是对目录增长模式的感知。建议团队先在每个构建后追加一行日志输出du -sh工作目录的最终大小，持续观测一周，掌握增长速率后再设定清理周期和阈值。等到策略稳定运行之后，构建机磁盘从“满”到“稳定在60%占用率”，这一整套工作目录清理工作才算真正结束——这也是云老大实践团队在服务多家企业CI/CD运维后验证过的路径，先诊断，后清理，再固化策略，三步缺一不可。
四、构建缓存清理与配置
前三部分的诊断方案，解决的是“当前磁盘为什么满”的问题。但正如前面所说，构建缓存才是真正让磁盘持续增长、反复触顶的长期变量。缓存清理之所以单独拿出来讲，是因为它处在「不能不动」和「不能乱动」之间：直接删除整个缓存目录，依赖拉取时间可能从几分钟暴涨到几十分钟；不清理，几轮构建后磁盘又回到临界点。实际运维中，缓存治理需要拆成三个动作依次落地：清空缓存、限制大小、开启复用。三步联动，才能把缓存从「隐患」变成「可控项」。
1. 清空缓存文件夹：先分清“冷热”，再动手执行
清空缓存文件夹，不是登录构建机执行一条 rm -rf 就完事。它的前提是分清哪些缓存是热的（高频使用，删了下次构建立即重建且耗时长的），哪些是冷的（低频或已失效，留着只是占空间）。
要清空的核心目录通常集中在三处：
- 包管理器缓存：npm 的
~/.npm、pip 的~/.cache/pip、Maven 的~/.m2/repository。这类缓存的特点是“时间越久，碎片越多”。npm 的_cacache目录在频繁迭代的项目里三个月涨到 10GB 以上非常常见，但其中真正在用的往往不到一半。 - 容器构建缓存：
/var/lib/docker下的 overlay2 层和 build cache。镜像构建是快照机制，每一层改动都会生成新的层，旧层不会被自动替换，只会堆叠。一个项目若每周发 5 个版本，一个月后 Docker 目录里躺着上百个无引用的中间层并不罕见。 - 通用临时文件：
/tmp目录下 CI 系统解压源码包留下的临时文件夹，通常被忽略，但日积月累也能达到 GB 级。
操作路径：先用 du -sh 逐个确认这三个目录的实时占用，再按冷热程度分级处理。
- 对于热缓存（当前活跃项目的依赖），不要删除，而是配合存储大小限制（见第 2 节）做“瘦身”。
- 对于冷缓存（已下线的依赖版本、超过 30 天未拉取过的镜像层），用以下命令精准清理：
# 清理 Docker 悬空镜像和构建缓存
docker image prune -af
docker builder prune -af
# 清理 npm 缓存
npm cache clean --force
# 清理 pip 缓存
pip cache purge
# 清理 Maven 下载缓存
mvn dependency:purge-local-repository -DmanualInclude=... # 按需指定
# 清理超过 10 天未被访问的构建临时目录
find /tmp/build-* -type d -mtime +10 -exec rm -rf {} +
这里有一个容易踩的细节：不要随意删除 ~/.m2/repository 中当前团队在用的依赖版本。Maven 团队如果共用同一个仓库配置，删了之后全组下一次构建会因重新下载而集体变慢。对于这类核心目录，优先使用 mvn dependency:purge-local-repository 的定向清理模式，而不是全量删除。
云老大团队的实际经验：在我们接手的某 SaaS 企业构建机中，/var/lib/docker 目录占了 60GB，但 docker image prune -af 清理后释放了 38GB——超过一半都是悬空镜像，而非正在运行的容器镜像。他们的构建任务在此之前每次跑到“打包镜像”阶段就报磁盘不足，清理后构建时长反而缩短了 12%，因为 Docker 不再需要为磁盘空间不足频繁执行 GC。这个案例说明：很多“磁盘不足”问题，本质是缓存膨胀问题，而清理后性能往往同步回升。
手动清理做到这个程度，只能算完成了 50% 的工作。剩下一半，在于怎么让它不再失控。
2. 限制缓存大小：从“清理存量”转为“控制增量”
如果只做第 1 步而不限制大小，缓存膨胀只是时间问题。限容的思路，是给缓存目录设一个“天花板”，从源头阻止磁盘被填满。限制手段按技术栈分为两层：
第一层：镜像/容器层限容
使用 Docker 作为构建工具的团队，为 Docker 根目录单独设置 storage-opts 的大小限制是最直接的方案。以常见的 devicemapper 或 overlay2 驱动为例：
# /etc/docker/daemon.json
{
"storage-driver": "overlay2",
"storage-opts": [
"overlay2.size=20GB"
]
}
设置后，容器层最大写入被限制在 20GB 以内。达到上限后 Docker 会拒绝写入并报错，此时触发清理策略（见第 3 节），而不是继续膨胀拖垮整个构建机。另一部分团队使用自建构建机并挂载独立数据盘，建议将 overlay2 的 size 调成数据盘大小的 50% 以下，保留充足的冗余空间给工作目录和制品。
第二层：包管理器缓存限容
npm 和 pip 本身不直接支持 size 上限配置，但它们都有 cache 目录迁移能力。常规方案是：
- 在
crontab中设定每周任务，统计~/.npm或~/.cache/pip的大小，超过阈值（如 5GB）后自动执行npm cache clean --force或pip cache purge。 - 使用
.npmrc中的cache-min参数控制缓存命中策略，缩短缓存的有效周期。
Maven 的 settings.xml 中可以通过
限容这一步，在云老大的实际交付中通常和「构建机合规检查」绑定——我们遇到不少客户在加完 storage-opts 后发现，生成出的镜像层大小反而更规范了，因为超限的中间层会被强制清理，粗放式构建被迫精简。这倒逼团队优化 Dockerfile 写法，比如合并 RUN 命令、减少不必要的 COPY，效果是构建产物体积平均下降了 20%~30%。
3. 开启缓存复用：跨任务复用依赖，减少重建次数，间接降低磁盘压力
开启缓存复用的意义，经常被误解为“只是个加速功能”。实际上，缓存复用是磁盘治理的“减负器”——复用率高了，构建过程需要新写入的依赖和镜像层就少了，磁盘增长速率会明显放缓，清理压力也随之降低。
云效构建系统对缓存的复用，体现在两个机制：
机制一：工作目录按构建任务隔离，但依赖缓存跨任务共享
同一台构建机上，不同任务的源码工作目录互相隔离，这是保障安全的前提。但是 npm cache、pip cache、~/.m2/repository 这类依赖缓存在同一构建机上是天然共享的。这意味着：
- 如果两个项目都使用 Vue 3 框架，第一个项目构建时已经把
vue相关依赖拉入 npm 缓存，第二个项目构建时直接命中缓存，无需重新下载。 - 但这也意味着，共享缓存区会持续累积多个项目的依赖（包含不同版本），膨胀速度比单一项目快数倍，因此必须和限容策略配合使用。
机制二：制品库的「复用策略」需要主动配置
云效支持构建任务通过设置“开启缓存复用”来避免每次构建从 0 开始。具体来说，构建环境中可以配置依赖目录白名单（cachePaths），将这些目录在任务结束后保留，下一轮构建时直接挂载复用。以体积最大的前端项目为例：
cache:
paths:
- node_modules
- .npm
key: "$CI_COMMIT_REF_NAME"
这里 key 按分支隔离，如果某个分支长期复用 node_modules 缓存，可以节省极大量的重复拉取时间。但需注意：复用是双刃剑。开启后如果依赖未更新，构建速度变快，但缓存目录存在大量过期依赖（如老版本 webpack），需要定期让该分支执行一次“全量构建”来刷新缓存，避免缓存目录只增不减。
复用策略的落地建议：
- 1 个构建机建议配置不超过 10 个高频复用 key，避免缓存组合数爆炸导致 Disk 占用失控。
- 固定 Release 分支（如 master/main）不要开启 cache:key 复用，或者设置为“更新依赖库时自动失效一次”，保证发版环境的构建缓存是“不区分历史包袱”的。
- 对缓存命中率进行监控：在构建站点的日志中观察依赖下载耗时与缓存命中情况。如果命中耗时长时间为 0，说明复用配置可能失效，需要检查 key 或目录映射是否变更。
关于缓存复用的常见误区：很多团队认为“开启复用 = 缓存一直有效”。实际上，依赖缓存的默认保留时长通常较短（CI 系统为了保证环境一致性，会让部分缓存周期过期）。云老大的运维经验建议，在构建机磁盘稳定的前提下，将复用配置周期性打包，比如一个季度做一次「全量缓存导出/导入」，这样能在长期复用中保持缓存目录的可用性与可控性，而不是让缓存在“长期不用”后被系统自动删光。
总结这一段的落地顺序：先清空冷缓存释放空间 → 配置 caps 限制后续增长 → 再开启复用减少重建压力。三步并非并列关系，而是递进关系。只在第 1 步停留的团队，会反复陷入“清空——用满——再清空”的循环；只做第 2 步而忽略复用，则每次构建都要重新下载依赖，变相增加了缓存写入频率和磁盘临时占用。三步配合，再叠加下一部分的制品生命周期管理，才能让构建机磁盘从“被动故障”转变为“主动可控”。云老大的客户反馈，这套三步走逻辑跑通一个月后，构建机磁盘使用率波动幅度明显收敛，故障工单量平均下降 60% 以上——有效治理缓存，本质上是在减少整个 CI 链路中的不确定性。
五、构建制品清理与保留
构建制品是三类磁盘占用中最容易理解、也最容易被忽视的部分。很多团队会为代码仓库配置分支保护规则，却很少有人为制品库设置保留期限——仿佛构建产物一旦生成，就天然有永久保存的价值。但现实是，一次生产发布可能只需要一个可回滚的版本，而每次CI运行都会留存一份完整的构建包。按平均每个包200MB计算，一天50次构建就是10GB的增量，一个月就是300GB。这不是理论推演，而是中大型团队构建机磁盘迅速见底的常见原因。
1. 删除历史构建包
清理历史构建包最直接的方式并非进入存储目录执行删除——云效的制品仓库提供了Web界面和命令行工具，可以按名称、版本号、时间范围筛选制品，手动或批量删除不再需要的构建产物。
这里的关键判断标准是：保留最近N个成功版本，其余全部视为可清理对象。例如生产环境保留最近5个可回滚版本，测试环境保留最近10个构建包，足以覆盖绝大多数代码回滚场景。实操中，可以先用制品库的版本列表功能按创建时间倒序排列，勾选超出保留范围的版本执行删除。执行前注意确认是否有已上线的发布单仍引用该制品，否则删除后可能导致生产环境回滚时找不到对应版本。建议在删除前先导出制品清单，或与发布单系统核对引用关系，避免“清理一时爽，回滚火葬场”。
2. 配置制品保留天数
手动删除解决的是存量问题，配置保留策略解决的才是增量问题。云效制品库的「保留策略」配置项支持按天数和版本数两种维度设置自动化清理规则：
- 按保留天数：设置制品自创建日起保留30天或60天，到期后由系统自动清理；
- 按版本数：每个仓库最多保留最近N个版本，超出部分的旧版本自动淘汰。
如果团队以快速迭代为主、发布频率高，建议设置保留天数更短（如30天）并辅以版本数双保险；如果制品需要满足合规审计或长期追溯要求，则按版本数限制（如保留200个版本）更合适，避免单纯按时间删除导致某个月的制品全部消失。两种策略可以并存，系统会以“更严格的那个条件”生效。配置完成后，建议在制品库观察一周确认清理动作正常执行，而不是配置完就不管了——不少团队的策略实际并未生效，原因是权限配置不当或规则优先级理解偏差。
3. 使用制品清理API
对于制品数量大、仓库数量多的团队，手动配置和界面操作效率太低，API方式更适合纳入自动化流程。云效提供的制品清理API支持按仓库、按时间范围、按保留版本数等条件批量执行清理任务，可以接入团队的定时任务系统（如Jenkins或云效流水线本身的定时触发），实现每周或每月自动巡检和清理。
一个更稳妥的实践是“先演练再执行”：在测试环境用API的查询接口先统计出可清理的制品列表，人工确认无误后，再在生产环境执行真正的删除操作。这样既保留了自动化的效率，也规避了误删风险。另外，建议清理API仅授权给CI运维专用的服务账号，不赋予普通开发者——删除操作不可逆，权限收紧是必要的安全边界。
在“先诊断、后清理”的运维框架下，构建制品的治理是其中合规性要求最明确的一环——因为它直接关联发布、回滚和审计需求。与工作目录和缓存的“实时可重建”不同，制品一旦删除无法找回，所以清理策略宁可保守，不可激进。云老大在服务客户时反复强调一个原则：制品清理配置完成之前，不要碰任何手动删除操作，先把规则定下来、验证跑通，再动手清存量。这条经验帮助不少团队绕过了“删完发现回滚不了”的坑。
制品清理本质上是对发布节奏的配套治理——发布越快，制品增长越猛，策略化的清理就越迫切。把它纳入CI/CD的日常运维范畴，磁盘空间问题才算真正闭环。
六、预防磁盘不足的实践
磁盘空间不足从来不是“突然的事故”，而是缓慢逼近的临界点。很多团队把清理当应急，手工删完缓存又能撑一阵，但问题复现的速度往往越来越快。云效构建磁盘空间不足清理的关键，不在于事后救火，而在于建立一套预防机制。结合云老大服务过的大中型CI节点运维经验，一个构建机的磁盘消耗主要来自三个固定路径：工作目录、依赖/镜像缓存、制品留存。如果能分别监控、分别设限，磁盘很难走到 No space left on device 那一步。
1. 监控磁盘剩余空间
监控不是看一个总剩余量就完了。工作目录、缓存目录、制品目录的增长曲线完全不同：工作目录呈锯齿状波动，构建完应清理；缓存目录是单调上升的，除非主动清理；制品目录则取决于保留策略。建议用 df -h 看整体用量，再用 du -sh 逐个路径定位，至少覆盖 /workspace（或自定义工作目录）、/root/.npm、/root/.cache、/var/lib/docker。更进一步，可以把这些目录的用量信息写入定时脚本——例如每30分钟记录一次，保留最近24小时，用简单脚本计算日增量。当某个缓存目录单日增长超过5GB，基本可以判定有异常依赖在膨胀。
云老大在给客户做构建机巡检时，发现不少节点就是缓存目录堆了大半年没动，从几GB涨到60GB以上，系统盘被悄悄吃满。这种监控的价值在于，你能提前预判下一次云效构建磁盘空间不足清理发生在哪一周，而不是等任务失败再去排查。
2. 优化构建依赖结构
监控解决“看见”，优化解决“少增长”。依赖缓存是磁盘占用的大头，尤其是Docker镜像层和npm依赖。建议从三个方向调整：
第一，把缓存目录独立出去。如果构建机有多块数据盘，将 /var/lib/docker、npm/yarn的cache目录、Maven本地仓库等挂载到独立磁盘，避免和系统盘抢空间。第二，限制单次构建能占用的缓存体积。Docker可以通过 storage-opts 限制容器层大小，npm可以设置 cache-max，Maven可以定期执行 dependency:purge-local-repository。第三，调整依赖管理方式。比如用pnpm替代npm，利用全局内容寻址存储让多个项目共享依赖副本。一个实际案例：某前端团队改造后，依赖占用从每个项目近2GB降到全局共享约6GB（支撑20个项目），整体磁盘用量下降约40%。这些调整不涉及业务代码变更，只改CI流水线和构建机配置，却能把磁盘增长曲线压平很多。
3. 配置磁盘上限告警
监控和优化之后，还需要最后一道防线：告警与自动处置。建议设置两级阈值：磁盘使用率超过85%时，触发“预清理”任务，自动执行 find <工作目录> -type d -mtime +3 -exec rm -rf {} +，同时清理悬空镜像（docker image prune -af）和过期的缓存；超过95%时，立即通知负责人在线介入，避免构建大面积失败。告警渠道可以是钉钉/企微机器人，也可以接入云效流水线通知。另外，制品的生命周期管理也属于告警的一部分——在制品库中配置保留30天或最近10个版本，过期自动淘汰，防止历史制品无限堆积。
云老大在落地服务中，通常会帮客户在构建机上部署一套这样的组合：磁盘用量统计脚本 + 老化清理任务 + 告警推送，整体配置半小时内完成。实践下来，云效构建磁盘空间不足清理的工单量能减少80%以上，构建稳定性明显提升，团队不用再半夜起来删缓存。预防的价值就在这里——用一次配置，换长期安心。
