cache-dir 设置后 CI 构建仍慢，根本原因是缓存未跨 job 持久化复用；需在 GitHub Actions/GitLab CI/Jenkins 中正确配置缓存路径与 key，并验证 composer diag、-v 日志及缓存目录大小。
cache-dir 设置后 CI 构建仍慢？先确认是否真生效
很多团队配了 cache-dir 却没提速，根本原因是 Composer 默认不会复用缓存——它只在本地有完整包时跳过下载，而 CI 每次都是干净环境，cache-dir 若未被正确挂载或复用，就等于没设。
- CI 中必须显式将
cache-dir目录设为持久化路径（如 GitHub Actions 的actions/cache，GitLab CI 的cache:key:paths） - 运行
composer install前，检查COMPOSER_CACHE_DIR环境变量是否已设且路径可写 - 执行
composer config --global cache-dir查看当前生效路径，避免被项目级composer.json中的config.cache-dir覆盖
如何让 cache-dir 在不同 CI 平台真正复用
关键不是“设路径”，而是“让缓存内容跨 job 保留”。不同平台策略差异大，不能只靠 composer config。
- GitHub Actions：用
actions/cache@v4缓存~/.composer/cache（注意路径需与COMPOSER_CACHE_DIR一致），key 推荐包含composer.lock的 hash 和 PHP 版本 - GitLab CI：在
cache:下指定key: ${CI_COMMIT_REF_SLUG}并声明paths: ["/root/.composer/cache"]（Docker executor 下默认用户是 root） - Jenkins：需配合
pipeline { agent any }+stash/unstash或共享 NFS 目录，不推荐用 workspace 缓存，易权限失败
cache:
key: ${CI_COMMIT_REF_SLUG}-composer-${CI_JOB_NAME}-${sha256sum composer.lock | cut -c1-8}
paths:
- /root/.composer/cachecache-dir 与 vendor 目录分离部署时的坑
自动化部署中常把 vendor 打包上传，但若 cache-dir 路径含绝对路径（如 /home/user/.composer/cache），CI 机器和目标服务器用户/路径不一致，会导致 composer install --no-interaction 失败或降级为全量下载。
- 始终用相对路径或环境变量定义
cache-dir，例如export COMPOSER_CACHE_DIR="${HOME}/.composer/cache" - 避免在
composer.json中硬编码"config": {"cache-dir": "/tmp/composer-cache"}，CI 和生产环境权限/生命周期不一致 - 使用
composer install --no-scripts --no-plugins加速部署阶段，插件加载可能绕过缓存逻辑
验证缓存是否起效的三个命令
别只看构建时间，要看 Composer 实际行为。以下命令必须在 CI job 内执行并输出日志：
-
composer diag：检查缓存目录是否存在、可写，以及是否启用压缩（cache-files-ttl影响命中率） -
composer install -v（verbose 模式）：观察日志中是否出现Downloading ... (cached)或Using version X from cache -
du -sh $COMPOSER_CACHE_DIR：首次构建后应 >100MB，后续构建增长缓慢才说明复用成功
最常被忽略的是 cache-files-ttl 默认 15 天，如果 lock 文件频繁更新但缓存里旧包未过期，Composer 可能拒绝复用——建议 CI 中加 composer config --global cache-files-ttl 0 强制跳过 TTL 校验。
