在 GitHub Actions 中缓存 composer 依赖的最佳实践-composer-PHP中文网

在 GitHub Actions 中缓存 composer 依赖的最佳实践

下次还敢

发布： 2025-11-10 19:00:03

原创

720人浏览过

使用 actions/cache 缓存 vendor 和 ~/.composer/cache 目录，基于 composer.lock 哈希生成 key，结合 restore-keys 提升命中率，确保 CI/CD 高效稳定。

在 github actions 中缓存 composer 依赖的最佳实践

在 GitHub Actions 中缓存 Composer 依赖可以显著加快 PHP 项目的 CI/CD 构建速度，避免每次都要重新下载所有依赖。关键是正确配置缓存键和恢复策略，确保命中率高且不会因缓存不一致导致问题。

使用 actions/cache 正确缓存 vendor 目录

Composer 安装的依赖默认放在 vendor 目录中，而依赖关系由 composer.lock 文件锁定。缓存应基于 lock 文件的哈希值来生成 key，这样只有当依赖变更时才重建缓存。

示例工作流片段：

- name: Cache Composer dependencies
  uses: 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 时。

可添加第二个缓存步骤：

GitHub Copilot

GitHub AI编程工具，实时编程建议

查看详情

- name: Cache Composer cache
  uses: actions/cache@v4
  with:
    path: ~/.composer/cache
    key: ${{ runner.os }}-composer-cache-${{ hashFiles('composer.lock') }}

这会缓存已下载的包归档，减少网络请求。注意该缓存 key 不需要 restore-keys，因为它是辅助性的。

确保 composer install 正确执行

即使有缓存，也应保证构建逻辑正确。建议使用以下命令：

- name: Install dependencies
if: 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 通常会跳过重复安装。