答案：通过 GitHub Actions 的 actions/cache@v4 缓存 Composer 依赖和 vendor 目录，基于 composer.lock 生成缓存键，可显著加速 PHP 项目构建，建议结合操作系统和 PHP 版本信息优化缓存命中率。
在使用 Composer 构建 PHP 项目时，依赖安装（composer install）往往是最耗时的步骤之一。特别是在 CI/CD 环境中，每次构建都从远程拉取所有包会显著拖慢流程。通过将 GitHub Actions 的 @actions/cache 与 Composer 结合，可以有效复用已下载的依赖包和已生成的自动加载文件，大幅缩短构建时间。
理解 Composer 的缓存路径
Composer 在运行过程中会将下载的包、元信息和日志等存储在本地缓存目录中。默认情况下，这个目录位于：
~/.composer/cache在 GitHub Actions 的 Linux 运行器中，用户主目录为 /home/runner，因此完整路径是：
/home/runner/.composer/cache缓存该目录后，后续构建可以直接复用之前下载的压缩包（dist files）、源码克隆（source clones）以及已解析的版本信息，避免重复网络请求。
配置 GitHub Actions 缓存策略
要在工作流中启用缓存，需在 YAML 文件中添加 actions/cache@v4 步骤，并指定缓存路径与缓存键（cache key）。以下是一个典型配置示例：
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
<pre class="brush:php;toolbar:false;"> - name: Cache Composer packages
id: composer-cache
uses: actions/cache@v4
with:
path: ~/.composer/cache
key: ${{ runner.os }}-composer-${{ hashFiles('**/composer.lock') }}
restore-keys: |
${{ runner.os }}-composer-
- name: Install dependencies
run: composer install --no-progress
GitHub Smart Code Digest — 自动监控仓库 Commits/PR，AI 智能代码审查，生成可视化审查卡片并汇总至飞书 Wiki。适用于团队代码质量追踪和工程管理者日报/周报生成。触发词：代码审查报告、GitHub 监控、PR 审查日报、代码质量汇总、工程师日报。
说明：
- path：指定要缓存的目录，即 Composer 缓存路径。
- key：基于操作系统和 composer.lock 文件内容生成唯一键。只要 lock 文件不变，就命中缓存。
- restore-keys：提供模糊匹配回退机制。若精确键未命中，尝试恢复以 ${{ runner.os }}-composer- 开头的缓存。
进一步优化：缓存 vendor 目录（可选）
除了 Composer 自身缓存，还可以直接缓存项目根目录下的 vendor 文件夹和自动加载优化结果。这种方式更激进，但需注意兼容性：
- name: Cache Vendor Directory
uses: actions/cache@v4
with:
path: |
vendor
bootstrap/cache/*.php
key: ${{ runner.os }}-vendor-${{ hashFiles('**/composer.lock') }}
搭配以下命令使用效果更佳：
composer install --no-progress --optimize-autoloader --classmap-authoritative这样可跳过整个依赖安装过程，前提是 lock 文件和 PHP 版本完全一致。
注意事项与最佳实践
- 始终基于 composer.lock 生成缓存键，确保依赖一致性。
- 避免缓存整个项目目录，容易因无关文件变动导致缓存失效。
- 定期清理旧缓存，GitHub 默认保留最近 7 天的缓存条目。
- 多 PHP 版本环境建议在缓存键中加入 PHP 版本变量，防止冲突。
基本上就这些。合理利用 @actions/cache 可让 Composer 安装从数十秒降至几秒，尤其在频繁提交的项目中收益明显。关键是找准缓存目标并设计稳定的缓存键策略。
