composer如何利用缓存加速持续集成_composer CI缓存配置【方案】

CI 中 composer install 慢的根本原因是每次构建都重新下载解压依赖并生成自动加载文件，必须同时缓存 vendor 目录和 COMPOSER_CACHE_DIR，并使用 –no-interaction –prefer-dist –optimize-autoloader 参数。

CI 中 composer install 为什么慢

根本原因是每次构建都重新下载全部依赖包，尤其是 vendor/ 目录重建 + ZIP 包解压 + 自动加载文件生成，叠加网络波动和 Packagist 响应延迟，单次耗时常超 2 分钟。缓存不是“可选优化”，而是 CI 稳定性的刚需。

必须启用的两个缓存层：vendor 和 Composer 自身 cache-dir

只缓存 vendor/ 不够——Composer 在安装前会先从 cache-dir 解包 ZIP、校验哈希、写临时文件；若 cache-dir 每次清空，仍要重复下载和解压。正确做法是同时持久化：

• vendor/ 目录（注意：需排除 vendor/bin/ 符号链接和部分生成文件）
• COMPOSER_CACHE_DIR 对应路径（默认 ~/.composer/cache），它存的是已下载的 ZIP 和 dist 包元数据

gitHub Actions 示例配置片段：

steps:   - name: Cache Composer dependencies     uses: actions/cache@v4     with:       path: |         vendor         ~/.composer/cache       key: ${{ runner.os }}-php-${{ hashFiles('**/composer.lock') }}-${{ hashFiles('**/composer.json') }}

composer install 必须加 –no-interaction –prefer-dist –optimize-autoloader

这三个参数缺一不可：

• --no-interaction：避免 CI 环境下因缺少 TTY 导致卡住（尤其某些插件会询问配置）
• --prefer-dist：强制走 ZIP 包安装（比 source 快 3–5 倍），且能命中 COMPOSER_CACHE_DIR 中的缓存包
• --optimize-autoloader：生成扁平化 autoload_classmap.php，跳过运行时文件扫描，PHP 加载类快 20%+，对测试启动时间敏感的场景明显

漏掉 --prefer-dist 会导致即使有 cache-dir，也绕过 ZIP 缓存走 git clone，彻底失效。

lock 文件变更时缓存失效策略要精准

缓存 key 若只基于 composer.lock 哈希，看似合理，但实际易误判：

• lock 文件里含平台配置（如 PHP 版本、扩展列表），CI 环境升级 PHP 后，旧缓存可能装错扩展兼容版本
• 某些私有仓库 Token 或镜像配置变更不会反映在 lock 中，但影响下载行为

推荐 key 组合：${{ runner.os }}-php-${{ matrix.php-version }}-composer-${{ hashFiles('**/composer.lock') }}，显式绑定 PHP 版本，避免跨版本缓存污染。私有源变动则需手动触发 cache 清理或增加配置哈希段。

真正麻烦的是 dev 依赖与 require-dev 的混用——它们出现在 lock 里，但 CI 测试阶段才需要。若缓存包含 dev 包，而 prod 构建误用了该缓存，会引入非预期依赖。建议按环境拆分 cache key，或统一用 --no-dev（生产构建）与 --with-all-dependencies（测试构建）隔离。