ci中composer install慢的本质是未正确使用缓存和--prefer-dist策略，导致反复git clone；需强制--prefer-dist、持久化composer_cache_dir、验证lock文件dist字段、私有包优先走dist发布并配置github token防限流。
CI里composer install慢，本质是没用对缓存和下载策略
默认走composer install在CI中反复拉源码、解压、安装依赖，尤其遇到git仓库或dev-分支时，会触发git clone，速度直接掉到秒级以下。核心不是网络差，而是没绕过源码构建路径。
--prefer-dist必须加，且要配合COMPOSER_CACHE_DIR
不加--prefer-dist，Composer默认倾向--prefer-source（尤其在dev模式或本地composer.json有repositories时），导致反复git clone。加上后强制走.zip包，快一个数量级。
但光加参数不够——CI每次都是干净环境，缓存目录不复用，.zip包还得重下。必须显式设置缓存路径并持久化：
- 在CI脚本开头设
export COMPOSER_CACHE_DIR=$HOME/.composer-cache - 把
$HOME/.composer-cache声明为缓存路径（GitHub Actions用cacheaction，GitLab CI用cache:paths） - 运行时加
--prefer-dist --no-progress --no-suggest（--no-progress减少IO，--no-suggest跳过无关提示）
别信composer.lock能自动解决一切
composer.lock确实锁定版本，但不锁定下载方式。如果lock文件里某包的dist信息缺失（比如本地开发时用require --dev加了git repo），CI仍会 fallback 到source。常见现象：Installing foo/bar (dev-main): Cloning abc123...——这就是坑。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
验证方法：检查lock文件中目标包的dist字段是否存在且含"url"和"shasum"；若只有"source"字段，说明它被记录为源码安装，需重新生成lock：
- 在干净环境（无
vendor/）下运行composer update --prefer-dist --no-dev（CI通常不需要dev依赖） - 提交更新后的
composer.lock
私有包或packagist.org不可达时，缓存失效怎么办
一旦用了私有repository（如type: composer或type: vcs），--prefer-dist可能退化——因为私有源未必提供dist包，或返回403导致Composer悄悄切回source。此时COMPOSER_CACHE_DIR对git clone几乎无效（git缓存不共享）。
应对思路很实际：
- 私有包尽量走
dist发布（如打包成.zip放HTTP服务器，配置dist.url） - 若必须
vcs，提前在CI镜像里git config --global url."https://token@github.com/".insteadOf "https://github.com/"，避免交互式认证阻塞 - 用
composer config -g github-oauth.github.com YOUR_TOKEN让GitHub API调用带token，防止限流
这些细节不处理，缓存再好也卡在第一个git clone上。
