GitHub Actions的Cache缓存为什么总是显示“Not found”？

看起来是缓存key的设置有点问题。首先检查下 hashFiles('**/package-lock.json') 这个路径是否真的能命中你的lock文件，尤其注意大小写和路径深度。

我建议你改用相对简单稳定的key结构，比如：

- name: Cache npm dependencies

  uses: actions/cache@v3

  with:

    path: node_modules

    key: ${{ runner.os }}-npm-${{ hashFiles('package-lock.json') }}

    restore-keys: |

      ${{ runner.os }}-npm-

记得把 hashFiles 直接指向项目根目录下的 package-lock.json 文件。这样即使开发依赖变动也不会影响整个缓存key，毕竟大部分情况下我们只关心生产依赖的变化。

另外提醒下，别忘了在安装依赖前执行这个缓存步骤，顺序很重要：

jobs:

  build:

    runs-on: ubuntu-latest

    steps:

    - uses: actions/checkout@v2

    - name: Cache npm dependencies

      ...

    - run: npm ci # 使用ci而不是install，效率更高

跑起来试试，这回应该能正常缓存起来了。折腾这些CI/CD的东西确实费时间，但调好了真能省不少构建时间。

这个问题很常见，主要是因为key的变化导致缓存匹配不上。你看，你用的是${{ hashFiles('**/package-lock.json') }}来生成key，而昨天修改了package.json里的依赖，这会直接导致package-lock.json发生变化，从而生成一个新的key。新key和之前的缓存key对不上，自然就显示“Not found”了。

标准写法其实你已经用了，但可以稍微调整一下策略。比如在restore-keys里多加一层容错：

- name: Cache npm dependencies

  uses: actions/cache@v3

  with:

    path: node_modules

    key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}

    restore-keys: |

      ${{ runner.os }}-npm-

      ${{ runner.os }}-

这样做的意思是，如果精确的key找不到，就会尝试用更宽泛的restore-keys去匹配之前的缓存。虽然可能不是完全匹配的依赖，但至少能减少重复安装的时间。

另外，提醒一下，如果你经常修改依赖，可以考虑把package-lock.json的hash改为package.json的hash，这样影响范围会小一点。不过这要看你的项目具体情况了。

最后，别忘了GitHub Actions的缓存是有生命周期的（默认14天），如果长时间没跑构建，缓存也可能被清理掉。这点文档里是有提到的，但很容易忽略...