必须先确认镜像源生效，再配置并发；执行composer config -g repo.packagist输出应为{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}，常见错误包括repos.packagist（多s）、url缺末尾/、项目级repositories覆盖全局，且必须执行composer clear-cache，否则镜像与http-max-concurrent-downloads=8等优化均无效。
镜像源配置错误，并行再高也白搭
国内用户不换镜像，http-max-concurrent-downloads设成20也没用——并发只是同时发请求，如果每个请求都卡在DNS解析或TLS握手（比如直连packagist.org），实际耗时可能比串行还长。必须先确认镜像已生效：composer config -g repo.packagist输出得是完整JSON，形如{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。常见错因：repos.packagist（多一个s）、URL末尾漏/、或项目级repositories字段直接覆盖全局配置。
并发参数别乱设，8是多数场景稳态上限
http-max-concurrent-downloads是Composer 2.2+唯一有效的并发控制项，旧版parallel-downloads已被废弃，写它会静默忽略。设为8是经过阿里云/清华镜像实测的平衡点：低于6提速不明显，高于10易触发429限流或file_put_contents(/tmp/): failed to open stream（临时文件竞争）。CI环境可临时用环境变量覆盖：COMPOSER_MAX_PARALLEL_HTTP_REQUESTS=6 composer install。注意：该参数对composer update效果有限，因其依赖解析阶段天然串行。
prestissimo这类插件现在就是累赘
如果你还装着hirak/prestissimo，立刻执行composer global remove hirak/prestissimo。Composer 2.1+已内置并行逻辑，该插件不仅失效，还会干扰HTTP客户端机制，导致日志里只显示Downloading (1/42)这种单数字跳变，实际降级为串行。验证是否真并发：跑composer install -vvv，看日志里是否同时出现多个Downloading https://行——没看到，说明并发被阻断，优先查composer --version（必须≥2.2）和PHP是否启用curl扩展。
缓存不清，镜像和并发全作废
composer clear-cache不是可选项，是必做动作。缓存里存着旧的packages.json和provider-*.json元数据，哪怕你刚切了阿里云镜像，Composer仍可能反复尝试从packagist.org拉索引，卡在DNS或TLS阶段。注意命令是clear-cache，不是cache-clear（后者已废弃）。验证是否清干净：加--no-cache跑一次composer install -vvv，看日志里实际请求的域名是不是你配的镜像地址。
真正卡住的地方往往不在下载本身——比如Resolving dependencies阶段慢，和镜像、并发完全无关，得去查composer.json里的约束是否太宽、minimum-stability是否设成dev，或者composer.lock有没有被误删。
