卡在“installing dependencies”主要是下载、解压或i/o问题；应升级composer≥2.2、设http-max-concurrent-downloads=10、换阿里云镜像并清缓存、用-vvv验证并发下载是否生效。
composer install卡在“Installing dependencies”怎么办
这阶段卡住，基本和依赖解析无关，是下载、解压或文件 I/O 出了问题。并发拉取没开、镜像源没换、临时目录争抢，三者占 90% 原因。
- 确认 Composer 版本 ≥ 2.2：
composer --version输出必须是Composer version 2.2.x或更高；若为 1.x，先跑composer self-update - 全局启用并发下载：
composer config -g http-max-concurrent-downloads 10（parallel-downloads在 2.2+ 已弃用，设了无效） - 设太高反而坏事：值 >10 容易触发
file_put_contents(/tmp/): failed to open stream，内存紧张时建议降到6或8 - 换阿里云镜像后必须清缓存：
composer clear-cache，否则旧元数据还在走packagist.org，并发也白开 - 验证是否真生效：
composer install -vvv看日志里是否多行Downloading https://同时出现，或进度显示类似(7/42) → (12/42)快速跳变
composer install卡在“Resolving dependencies”怎么破
这不是网络慢，是本地 CPU 在暴力穷举版本组合。尤其当 composer.json 里写了 "^1.0 || ^2.0" 或 "*" 这类宽泛约束时，求解器会指数级爆炸。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 临时绕过：加
--no-cache再试一次，有时比等 5 分钟更有效（尤其当缓存损坏时） - 收紧 PHP 版本约束：
"php": "^8.1"比"php": ">=7.4"少查几百个包的兼容性元数据 - 禁用 xdebug：
php -d zend_extension= -d xdebug.mode=off /usr/bin/composer install，它会让解析慢 5–10 倍 - 检查私有源是否拖后腿：
composer config --list看有没有指向已下线或超时的repositories，临时绕过可用--repository=https://packagist.org - 确保
composer.lock已提交进 Git，并在 CI/部署中始终用composer install，而非无条件composer update
composer clear-cache 到底该不该清、什么时候清
composer clear-cache 不是万能加速键，它只对特定缓存污染场景有效，对语法错误、PHP 版本不匹配、xdebug 开启等问题完全无效。
- 该清的情况：
composer install卡在Loading composer repositories；换镜像后仍报Could not load package xxx in http://repo.packagist.org；strace -e trace=openat,open,read composer install 2>&1 | grep cache显示反复读取损坏的.zip文件 - 不该清的情况：编辑器卡顿、IDE 补全慢、PHP 启动慢——这些和 Composer 缓存无关，应查
xdebug、opcache.validate_timestamps或项目目录下巨量未忽略文件（如node_modules/） - 清完必须验证：
composer config -g repo.packagist输出应为完整 URL（如https://mirrors.aliyun.com/composer/），不能是null或空值 - 别信“清缓存就变快”的玄学：如果
composer config -g http-max-concurrent-downloads还是默认6、镜像源仍是packagist.org，清完照样卡
CI/CD 中怎么避免 Composer 成为瓶颈
CI 环境里最常见反模式是无条件 composer update，它强制重算整个依赖图，还可能触发大量远程元数据拉取。
- CI 中只用
composer install --no-interaction --no-scripts --no-dev --prefer-dist --optimize-autoloader --classmap-authoritative，靠composer.lock保证一致性 - 缓存路径必须可控：
COMPOSER_CACHE_DIR=/tmp/composer-cache并确保该路径可写、非 NFS、不在 OneDrive/Dropbox 同步目录内 - 禁用脚本执行：
--no-scripts能省 1–3 秒，尤其当你不需要post-install-cmd - CLI 场景慎用 APCu：
apcu-autoloader配置只对 Web 请求有效，且需配对composer dump-autoload；CLI 下若开启opcache.enable_cli=1，反而可能掩盖类加载问题 - 旧插件必须卸载：
composer global remove hirak/prestissimo，它在 Composer 2.x 中已失效，还会静默干扰新版调度逻辑
http-max-concurrent-downloads 和 repo.packagist 这两个配置项，一个设错就等于没开并发，一个配错就等于白换镜像；而 --classmap-authoritative 在开发环境误用，会导致新增类直接找不到——这些都不是文档里一句“推荐开启”就能带过的。
