使用 actions/cache 缓存 vendor 和 ~/.composer/cache 目录，基于 composer.lock 哈希生成 key，结合 restore-keys 提升命中率，确保 CI/CD 高效稳定。
在 GitHub Actions 中缓存 Composer 依赖可以显著加快 PHP 项目的 CI/CD 构建速度，避免每次都要重新下载所有依赖。关键是正确配置缓存键和恢复策略，确保命中率高且不会因缓存不一致导致问题。
使用 actions/cache 正确缓存 vendor 目录
Composer 安装的依赖默认放在 vendor 目录中，而依赖关系由 composer.lock 文件锁定。缓存应基于 lock 文件的哈希值来生成 key，这样只有当依赖变更时才重建缓存。
示例工作流片段：
- name: Cache Composer dependenciesuses: actions/cache@v4
with:
path: vendor
key: ${{ runner.os }}-composer-${{ hashFiles('composer.lock') }}
restore-keys: |
${{ runner.os }}-composer-
说明：
- path: vendor 指定缓存实际安装的依赖目录
- key 包含操作系统和 lock 文件内容哈希，确保环境与依赖一致
- restore-keys 提供降级匹配机制，比如 lock 文件变更后可尝试使用旧缓存加速部分下载
同时缓存 Composer 的全局缓存目录（推荐）
除了 vendor 目录，Composer 自身会缓存包文件（如 zip 归档）在全局目录中。缓存这个路径能进一步提升性能，尤其是跨多个项目或 job 时。
可添加第二个缓存步骤：
uses: actions/cache@v4
with:
path: ~/.composer/cache
key: ${{ runner.os }}-composer-cache-${{ hashFiles('composer.lock') }}
这会缓存已下载的包归档，减少网络请求。注意该缓存 key 不需要 restore-keys，因为它是辅助性的。
确保 composer install 正确执行
即使有缓存，也应保证构建逻辑正确。建议使用以下命令：
- name: Install dependenciesif: steps.cache-composer-dependencies.outputs.cache-hit != 'true'
run: composer install --no-progress --no-scripts --prefer-dist
或者更常见的是无条件运行 composer install，但启用 --prefer-dist 和 --no-dev（如为生产构建），并让 Composer 利用已有的 vendor 目录智能判断是否重装。
如果 vendor 已存在且 lock 文件未变，Composer 通常会跳过重复安装。
注意事项与最佳实践
- 始终提交 composer.lock 文件，这是缓存有效的前提
- 避免缓存整个项目目录，只缓存必要的路径（vendor、~/.composer/cache）
- 定期清理旧缓存，GitHub 会自动管理，但可通过 UI 手动清除损坏缓存
- 若使用私有包，确保认证已配置（如通过 COMPOSER_AUTH 环境变量）
- 不同 PHP 版本或扩展组合可能导致兼容问题，可在 key 中加入 PHP 版本标识（如 ${{ matrix.php-version }}）
基本上就这些。合理利用缓存键和分层缓存策略，能大幅缩短构建时间，同时保持可靠性。
