Composer怎么利用缓存？提升多人协作安装速度方案

先给个核心判断：缓存没用对，多人协作时 vendor 重建就是常态。问题出在哪？不是网络不给力，是缓存路径、key、生命周期这三者没对齐。

很多团队在本地开发时，~/.composer/cache/files/ 目录是默认存在的，但一到 CI 流水线里，如果没人显式声明 cache: paths:，那 vendor/ 和 .composer/cache/ 根本不会跨 job 保留。常见误区是只写 cache: paths: - vendor/，看起来没毛病，实际上 Composer 自身的缓存没跟着走，下次 composer install 还得从头下载 zip 包。

那么正确的做法是什么？

• 缓存 vendor/ 只是第一步，还必须同时缓存 ~/.composer/cache/（或 $COMPOSER_HOME/cache/），两者缺一不可。
• 缓存 key 要足够稳定。用 ${CI_COMMIT_REF_SLUG}-${CI_PIPELINE_ID} 比直接套 ${CI_COMMIT_TAG} 靠谱得多——后者在非 tag 的流水线里会 fallback 到默认键，等于白配。
• 私有包的情况更要留心：提前把 composer auth 配置注入到 CI 变量里。否则缓存虽然拉下来了，composer install 却因为认证失败退化为重新拉取，跟没缓存一样。

缓存失效的三个典型信号

缓存开关看似都开了，实际到底命没命中？有几个很直观的检查方式：

• composer install 日志里反复出现 Downloading ... 字样，同时 .composer/cache/files/ 目录下面空无一物。
• CI 构建时间波动极大，同一 commit 有时 2 分钟跑完，有时飙到 8 分钟。
• 用 composer show -p 确认源地址是对的，但 strace -e trace=openat,connect 一看，居然还在连海外 IP。

根因其实就几个：缓存 key 配错了、COMPOSER_HOME 路径没统一、或者镜像源切换后没清旧缓存。需要提醒的是，composer clear-cache 一定要跟在换源命令后面执行，顺序反了就白清。

本地与 CI 缓存策略要错开

开发机和 CI 环境的目标本来就不一样，缓存配置不能一刀切。

• 本地开发建议设 composer config -g cache-files-ttl 15552000（也就是 6 个月），避免频繁失效，省心省力。
• CI 环境的 TTL 则要短一些，或者依赖 key 变更来自动刷新，防止 stale cache 污染构建结果。
• 另外，CI 里千万别跑 composer self-update——它会直接改写 .composer/ 下的二进制和配置，紧接着缓存就可能失效。
• 团队共用的 Dockerfile 里，RUN composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 必须放在 composer install 之前，而且保证不被后续步骤覆盖掉。

还有一个更隐蔽的问题：缓存和 composer.lock 之间其实有耦合关系。lock 文件里记录的 dist URL 如果仍然指向 packagist.org，哪怕全局配了阿里云镜像，Composer 也可能 fallback 回源去校验 hash。遇到这种情况，别在参数上死磕——直接把 vendor/ 和 composer.lock 删掉，重新生成一次，反而更干脆。