Composer怎么利用缓存?提升多人协作安装速度方案
Composer多人协作速度慢源于缓存路径、键值与生命周期未对齐。正确做法是同时缓存vendor/和~/.composer/cache/,使用稳定缓存键如CI_COMMIT_REF_SLUG。私有包需提前注入认证配置。本地与CI的缓存TTL应差异化,CI中避免composerself-update,镜像源配置必须在composerinstall之前。缓存未命
先给个核心判断:缓存没用对,多人协作时 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 删掉,重新生成一次,反而更干脆。
































