Composer 运行慢主因是未启用并行下载、未换国内镜像源、关键参数漏配；需 Composer 2.2+、设 parallel-downloads=10、配阿里云镜像、清缓存，并在 CI 中禁用脚本与自动加载。
Composer 运行慢，95% 不是网络差，而是并行下载没开、镜像源没换、关键参数漏配——三者缺一不可。单独调高并发或只换源，提速不到一半。
确认 Composer 版本是否支持并行下载
Composer 2.2+ 才真正支持 parallel-downloads，低于此版本（比如 1.x 或 2.1.x）压根不识别该配置，设了也白设。
- 运行
composer --version，输出必须是Composer version 2.2.x或更高；若为1.x，立刻执行composer self-update - 检查当前值：
composer config -g parallel-downloads，返回空表示未启用，返回3是默认值（基本等于没开） - 旧插件如
hirak/prestissimo必须卸载：composer global remove hirak/prestissimo，否则会静默干扰新版调度逻辑
正确设置并行下载并发数
parallel-downloads 是唯一有效的并发控制项（http-max-concurrent-downloads 在 2.2+ 已被弃用，设了也不起作用），但它不是越高越好。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 全局设为
10是多数开发机的安全上限：composer config -g parallel-downloads 10 - 若报错
file_put_contents(/tmp/): failed to open stream，说明临时文件争抢严重，立即降到6或8 - 别设
20或更高：镜像站会限流，本地 DNS / TLS 握手也可能超时，反而触发大量重试 - 该配置仅对
composer install生效；composer update因依赖图实时计算，仍存在明显串行段
必须搭配国内镜像源才有效
并发只是“同时发请求”，如果每个请求都卡在 DNS 解析、TLS 握手或回源失败，并行毫无意义。
- 推荐阿里云镜像（最稳）：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 换源后务必清缓存：
composer clear-cache，否则旧元数据仍在偷偷走 packagist.org - 验证是否生效：
composer config -g repo.packagist输出必须是完整 URL，不能是null或空值 - 已停更的源（如
https://packagist.phpcomposer.com）会返回 404，千万别用
CI/CD 中必须关闭冗余环节
开发时需要 autoload 和脚本，但 CI 构建或生产部署时，它们全是纯开销。一个含上百包的项目，post-install-cmd 和自动生成 autoload 可吃掉 30%+ 时间。
- CI 脚本中固定使用：
composer install --prefer-dist --no-dev --no-scripts --no-autoloader --optimize-autoloader -
--no-autoloader跳过生成vendor/autoload.php，后续用composer dump-autoload --optimize单独补 -
--no-scripts阻止执行前端构建、缓存清理等重型钩子，避免意外触发npm install或redis flushdb -
--prefer-dist强制走压缩包而非 Git 克隆，它和parallel-downloads是咬合生效的——没它，并行拉的可能是大体积源码包，解压反而更慢
最容易被忽略的是：镜像配置和并行下载必须一起开；还有就是 composer.lock 是否由同源生成、是否提交到仓库——换源后若 lock 文件里还残留海外 dist URL，install 仍会回源。
