答案：通过缓存 Composer 全局包缓存目录 ~/.composer/cache 并基于操作系统和 composer.lock 文件生成缓存键，结合 restore-keys 回退机制，在 GitHub Actions 中可显著加速 PHP 项目依赖安装；需配合 --prefer-dist 和 --optimize-autoloader 等参数确保效率，并注意提交 composer.lock、管理缓存大小及多环境下的键值区分。
在 GitHub Actions 中高效缓存 Composer 依赖，能显著减少 PHP 项目每次构建时的依赖安装时间。关键是正确使用 actions/cache 并精准指定缓存路径与键值策略。
识别需要缓存的目录
Composer 默认将下载的依赖包存储在本地缓存目录中，这个路径通常是 ~/.composer/cache。同时，项目中的 vendor 目录是安装路径，但一般不直接缓存它，而是通过锁定 composer.lock 文件配合缓存源码来加速 composer install。
你应该缓存的是 Composer 的全局包缓存，而不是 vendor 目录本身。这样在不同 job 或 workflow 运行中可以复用已下载的 zip 包和 dist 文件。
配置缓存步骤
在工作流文件中添加缓存步骤，放在执行 composer install 之前：
- name: Cache Composer dependenciesuses: actions/cache@v4
with:
path: ~/.composer/cache
key: ${{ runner.os }}-composer-${{ hashFiles('**/composer.lock') }}
restore-keys: | ${{ runner.os }}-composer-
说明：
- path：Composer 缓存的实际路径，Linux 和 macOS 是 ~/.composer/cache，Windows 可能略有不同（runner 自动处理）
- key：基于操作系统和 composer.lock 文件内容生成唯一键。只要 lock 文件不变，就命中缓存
- restore-keys：提供回退机制，当精确 key 不匹配时，尝试恢复最近一次的缓存
确保 composer 命令高效运行
缓存生效后，还需确保 composer install 执行时不绕过缓存：
- 使用 --no-progress 和 --prefer-dist 提高效率
- 避免使用 --prefer-source，它会跳过缓存的 dist 包
- 建议添加 --optimize-autoloader（生产环境用 --classmap-authoritative）
run: composer install --no-progress --prefer-dist --optimize-autoloader
注意事项与最佳实践
为了保证缓存的准确性和效率，请注意以下几点：
- 始终提交 composer.lock 文件，它是缓存 key 的基础
- 如果项目使用私有包或自定义镜像，确保 auth.json 配置正确，不影响缓存逻辑
- 缓存大小默认限制为 5GB，频繁变更依赖可能导致缓存碎片，可定期清理旧缓存
- 多个 PHP 版本或架构的项目应确保缓存 key 包含相关变量，如：
${{ runner.os }}-php-${{ matrix.php-version }}-composer-${{ hashFiles('**/composer.lock') }}
基本上就这些。合理利用缓存 key 策略和路径配置，能让 Composer 依赖安装从几十秒降到几秒。不复杂但容易忽略细节。
