GitHub Actions怎么缓存composer依赖_教你在GitHub Actions中缓存composer依赖

通过缓存 Composer 依赖可显著提升 GitHub Actions 部署 PHP 项目的效率。首先使用 actions/cache 缓存 ~/.composer/cache 和 vendor 目录，利用 composer.lock 文件的哈希值生成缓存 key，确保依赖变更时缓存失效；配置 restore-keys 提供回退机制，优先缓存 Composer 下载缓存以加速安装过程。需确保提交 composer.lock、处理私有包认证，并定期清理旧缓存。合理配置可大幅缩短构建时间，关键是通过 hashFiles('**/composer.lock') 精确控制缓存有效性。

在使用 GitHub Actions 部署 PHP 项目时，每次运行工作流都会通过 Composer 安装依赖，这会增加执行时间。通过缓存 Composer 依赖，可以显著提升 CI/CD 流程的效率。下面教你如何正确配置缓存机制。

为什么需要缓存 Composer 依赖

Composer 安装依赖通常耗时较长，尤其是当项目依赖较多或网络不稳定时。启用缓存后，GitHub Actions 会保存 vendor 目录和 Composer 缓存目录，下次构建时命中缓存可跳过重复下载，加快流程。

使用 actions/cache 缓存依赖

GitHub 提供了 actions/cache 动作，可用于缓存任意文件夹。我们主要缓存两个路径：

• ~/.composer/cache：Composer 下载的压缩包缓存
• vendor：项目依赖安装目录

以下是一个典型的 workflow 配置示例：

yml
name: CI
on: [push, pull_request]

							

								
								

									Cutout.Pro抠图
									
AI批量抠图去背景
								
								下载 
							
						
jobs:
build:
runs-on: ubuntu-latest
steps:
name: Checkout code
uses: actions/checkout@v4
name: Setup PHP
uses: shivammathur/setup-php@v2
with:
php-version: '8.1'
tools: composer
name: Cache Composer dependencies
uses: actions/cache@v3
with:
path: ~/.composer/cache
key: ${{ runner.os }}-composer-${{ hashFiles('**/composer.lock') }}
restore-keys: |
${{ runner.os }}-composer-
name: Install dependencies
run: composer install --no-progress --no-scripts
name: Cache vendor directory
uses: actions/cache@v3
with:
path: vendor
key: ${{ runner.os }}-vendor-${{ hashFiles('**/composer.lock') }}

说明：

• key 使用 composer.lock 文件的哈希值，确保依赖变更时缓存失效
• restore-keys 提供回退机制，提高缓存命中率
• 先缓存 Composer 下载缓存，再安装依赖，最后尝试缓存 vendor 目录（可选）

优化建议与注意事项

为了获得最佳效果，请注意以下几点：

• 确保 composer.lock 文件已提交到仓库，它是缓存命中判断的关键
• 如果使用私有包，需配置认证信息（如 GitHub Token）
• 避免缓存整个 vendor 目录时出现兼容性问题，推荐优先缓存 ~/.composer/cache
• 定期清理旧缓存，可在 GitHub 仓库的 "Settings > Actions > General > Manage artifacts and caches" 中操作

基本上就这些。合理使用缓存能大幅缩短构建时间，尤其对频繁推送的项目帮助明显。不复杂但容易忽略细节，关键是用好 hashFiles('composer.lock') 来控制缓存有效性。