<p>配置Composer缓存可显著提升GitLab CI中PHP项目的构建速度，核心是缓存vendor目录或Composer全局缓存路径。直接缓存vendor/虽高效但需确保composer.lock提交且团队协作时注意依赖更新风险；推荐做法是缓存~/.composer/cache以避免项目不一致问题。通过在.gitlab-ci.yml中设置cache: key: $CI_COMMIT_REF_SLUG paths: - ~/.composer/cache，结合before_script中配置缓存有效期和composer install命令，实现跨作业高效复用依赖。完整流程包括定义stages、设置缓存键、执行依赖安装与测试，并建议始终提交composer.lock、避免多环境共享vendor、定期清理旧缓存及使用--prefer-dist优化下载方式。合理配置后依赖安装时间通常可减少50%以上。</p>
在GitLab CI中配置Composer缓存能显著加快PHP项目的构建速度，避免每次安装依赖都从远程下载。关键是将vendor目录和Composer缓存目录加入缓存机制。
启用vendor目录缓存
最直接的方式是缓存项目中的vendor目录，这样依赖包无需重复安装。
composer.lock未提交或团队协作频繁更新依赖，可能引发问题。在.gitlab-ci.yml中添加：
cache:
paths:
- vendor/
该配置会跨作业保留vendor文件夹，但建议结合key使用，避免不同分支间缓存污染。
缓存Composer用户目录
更推荐的做法是缓存Composer的全局缓存路径（$COMPOSER_CACHE_DIR），它存储了已下载的包归档文件，不影响项目一致性。
默认路径为~/.composer/cache，可在CI中指定：
cache:
key: $CI_COMMIT_REF_SLUG
paths:
- ~/.composer/cache
使用$CI_COMMIT_REF_SLUG作为缓存键，确保不同分支使用独立缓存。
完整CI配置示例
以下是一个典型配置：
stages: - install - test <p>cache: key: $CI_COMMIT_REF_SLUG paths:</p><ul><li>~/.composer/cache</li></ul><p>before_script:</p><ul><li>composer config cache-files-ttl 86400 # 缓存1天</li><li>composer install --no-progress --no-scripts</li></ul><p>install_deps: stage: install script:</p><ul><li>echo "Dependencies installed."</li></ul><p>run_tests: stage: test script:</p><ul><li>vendor/bin/phpunit
这个流程先恢复Composer缓存，再执行composer install，命中缓存后下载速度大幅提升。
注意事项与优化建议
为了确保缓存高效且安全，注意以下几点：
- 始终提交
composer.lock，保证依赖版本一致 - 避免缓存
vendor目录时在不同PHP版本或架构间共享缓存 - 定期清理旧缓存，防止占用过多CI存储
- 使用
--prefer-dist选项优先下载压缩包而非克隆源码
基本上就这些。合理配置缓存后，大多数项目的依赖安装时间可减少50%以上。关键在于选择合适的缓存路径并管理好缓存键。
