CodeArts 流水线构建提速：缓存命中的五个实操点

流水线跑得慢，多数时候不是机器不够，而是同样的依赖和中间产物被反复重新构建。本文把 CodeArts 流水线（以及同类 CI/CD 平台通用）的缓存提速拆成五个可以逐个落地的点，每个都给出可执行配置，不分先后、按你的瓶颈选着做。

一、依赖缓存：让 Maven / npm / pip 命中本地仓库

最常见的浪费时间：每次构建都重新下载全部依赖。做法是把依赖目录挂到持久化缓存，并保证缓存 key 只随依赖声明变化、不随代码每次提交变化。

# CodeArts 流水线任务（YAML 片段）
jobs:
  build:
    cache:
      key: deps-{{ checksum "pom.xml" }}
      paths:
        - ~/.m2/repository   # Maven
        # - node_modules      # npm（或 .npm 缓存目录）
        # - ~/.cache/pip      # Python
    steps:
      - run: mvn -B package -DskipTests

要点：

1. key 里只放依赖声明文件的校验和（<code>pom.xml</code> / <code>package-lock.json</code> / <code>requirements.txt</code>），不要放提交号或时间戳——否则每次提交都失效，等于没缓存。 2. Maven 构建时加 <code>-o</code>（离线模式）做一次验证：离线能过，说明依赖缓存完整命中。 3. npm 用 <code>npm ci</code> 而非 <code>npm install</code>，它按 lockfile 严格安装，配合缓存目录更快也更可复现。

二、Docker 镜像分层缓存：把「变化最少的层」放前面

如果用 Dockerfile 构建镜像，依赖安装层应该放在代码 COPY 之前。只要依赖没变，前面几层就能直接命中缓存，只重建代码层。

FROM node:20-slim
WORKDIR /app

# 依赖层在前：package.json 变化频率远低于源码
COPY package.json package-lock.json ./
RUN npm ci

# 代码层在后：每次提交都变化
COPY . .
CMD ["node", "server.js"]

判断标准：改动一个源码文件后重新构建，如果 <code>RUN npm ci</code> 那一层没有重新执行，分层缓存就生效了；如果每次都重装依赖，说明 COPY 顺序写反了，或 CI 平台没有开启镜像层缓存。

三、增量编译：给编译型项目开增量开关

Java / C++ / Go 这类编译型项目，全量重编译是最大的时间黑洞。优先确认构建工具本身是否在增量编译：

· Maven 侧：mvn -B package -DskipTests -Dmaven.compiler.useIncrementalCompilation=true，并把 target/ 放进缓存 paths；Spring Boot 项目常用 DevTools 做热更新增量编译，正式流水线里保证 target 缓存命中即可。

· Go：go build 本身有 build cache（GOCACHE），把 GOCACHE 指到缓存目录即可跨任务复用。

· 若使用 ccache：设置 CCACHE_DIR 并加进缓存 paths，C/C++ 项目的重复编译能接近秒级命中。

增量编译的副作用是「第一次慢、后续快」，所以缓存目录必须持久化，而不是每次构建用全新容器。

四、缓存失效的四个隐藏原因（按出现频率排）

1. <strong>缓存 key 过粗或过细</strong>：key 含时间戳/提交号 → 次次失效；key 不含依赖文件 → 依赖变了还用旧缓存 → 构建通过但运行出错。正确做法是依赖声明文件的校验和。 2. <strong>目录没进缓存</strong>：Maven 缓存写到了 <code>~/.m2</code>，但流水线只缓存了 <code>target/</code>；npm 缓存写在 <code>~/.npm</code> 而非 <code>node_modules</code>。先确认路径真实存在，再确认写入方向（读缓存与写缓存是同一路径）。 3. <strong>缓存未持久化</strong>：某些快速构建环境容器用完即销毁，缓存只在单次任务内生效。需要平台级持久缓存或自建缓存服务器（如 Nexus / Artifactory 仓库代理）。 4. <strong>多任务并发写同一缓存</strong>：并行任务同时读写同一缓存目录会互相覆盖或锁竞争。按分支/模块拆分缓存 key，或让缓存目录只读共享、构建产物各自独立。

五、先量化再优化：五分钟找到真正的瓶颈

改任何一处之前，先记录两次构建的耗时分布（拉取依赖 / 编译 / 打包 / 上传镜像各占多少），改完再复测同一指标，避免「优化了个寂寞」：

# 示例：连续 3 次构建，记录总耗时，取中位数
for i in 1 2 3; do
  /usr/bin/time -f "%e" mvn -B package -DskipTests 2>&1 | tail -1
done

对比标准：依赖下载段下降最明显说明缓存 key 和路径配对了；编译段下降说明增量编译生效；如果总耗时没变，先别急着加缓存，去查构建机规格和网络带宽。

---

总结成一句话：缓存 key 绑定依赖声明、缓存路径指向真实目录、镜像层顺序把依赖放前面、编译开增量、改前先量化。这五点不依赖特定平台，CodeArts 流水线的缓存配置界面只是这五个点的图形化封装，原理完全一致。