多人协作时vendor重建常态源于缓存路径、key、生命周期未对齐：本地~/.composer/cache默认存在，CI需显式缓存vendor/和$COMPOSER_HOME/cache/，key用${CI_COMMIT_REF_SLUG}-${CI_PIPELINE_ID}更可靠，私有包须预置auth，缓存失效信号包括反复下载、构建时间波动大、strace显示连海外IP。
缓存没用对，多人协作时 vendor 重建就是常态——不是网络问题，是缓存路径、key、生命周期三者没对齐。
为什么团队里有人快有人慢？缓存根本没共享
本地开发时 ~/.composer/cache/files/ 默认存在，但 CI 流水线里没人显式声明 cache: paths:，vendor 和 .composer/cache/ 就不会跨 job 保留。GitLab CI 写个 - vendor/ 就完事？不行——只缓 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 变量，否则缓存虽在，install仍会因认证失败退化为重拉
缓存失效的三个典型信号
缓存看似开了，但实际不命中，常见现象：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
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 重生成，比硬调参数更干脆。
