首页/开发/CI/CD 与发布速查/缓存键设计(Cache Key)
流水线设计54 条

缓存键设计(Cache Key)

缓存键决定命中率与正确性:按依赖锁文件哈希生成键,依赖变更自动失效,避免用错缓存。

CI/CD 与发布速查开发更新于 2026-10-13

缓存键怎么设计

缓存键决定命中率与正确性:按依赖锁文件哈希生成键,依赖变更自动失效,避免用错缓存。GitLab 用 cache:key:files 以文件内容生成键(上限 2 个文件);GitHub 的缓存动作常用文件哈希函数计算锁文件摘要;分层键用 restore-keys 提供前缀回退,允许部分命中。设计口径:键跟随依赖源变化,而不是跟随时间或提交号。键过于笼统(如固定 v1)会命中过期依赖;键过于具体(含提交号)则几乎无法复用。

基本信息

GitLabcache:key:files 用文件内容生成键(上限 2 个文件)
GitHub缓存动作的 key 常配文件哈希函数计算锁文件摘要
分层键restore-keys 提供前缀回退,允许部分命中
设计口径键跟随依赖源变化,而不是时间
分支隔离按分支或引用加前缀避免互相污染

典型使用场景

  • 依赖缓存:lockfile 哈希作为键,依赖变更自动换缓存。
  • 分层回退:先精确命中,未命中退回前缀缓存实现部分命中。
  • 分支隔离:键加分支前缀,避免功能分支与主干互相覆盖。
  • 多包管理器:npm、pip、Go 各自建键,互不干扰。
  • 命中率监控:观察命中率变化定位键设计问题。
  • 清缓存演练:定期从空缓存跑一次,确认流程不依赖缓存也能通过。

GitHub 分层键

GitHub 分层键
- uses: actions/cache@v4
  with:
    path: ~/.npm
    key: npm-${{ runner.os }}-${{ hashFiles('**/package-lock.json') }}
    restore-keys: |
      npm-${{ runner.os }}-

GitLab 按锁文件

GitLab 按锁文件
cache:
  key:
    files: [package-lock.json]
键过于笼统会命中过期依赖,键过于具体则几乎无法复用,取中间:依赖源摘要加环境前缀。
缓存写入是尽力而为:缓存服务不可用或未命中时,作业必须能回退全量安装,正确性不能依赖缓存。
只读作业可以配置为只用不写:避免并发上传互相覆盖,上传统一交给一个作业。

易错点

  • 文件哈希函数找不到匹配文件时返回空串:键退化为固定值导致错误复用,定期验证通配路径与真实文件名。
  • 多个缓存路径共用一个过宽键:内容不一致的数据被同一缓存带进来,互相覆盖。
  • 键含提交号:缓存几乎从不命中,等于没有缓存,还白占存储。
  • 分支之间共享键且互相覆盖:新分支写入的缓存污染主干,按引用加前缀隔离。
  • 把缓存当正确性来源:命中失败必须能回退全量安装,否则缓存清理会让流水线随机失败。

数据来源与参考

  • GitLab Docs《Cache key》
  • GitHub Docs《Caching dependencies》
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌