Composer 2.x 原生支持并行下载，无需 prestissimo；提速关键在于 --prefer-dist、提交 composer.lock、使用镜像源及优化 autoloader，而非第三方插件。
Composer 2.x 自带并行下载，无需额外二进制加速
Composer 从 2.0 开始已原生支持并行 HTTP 下载（基于 cURL multi），composer install 默认就用上它了——你不需要装 hirak/prestissimo 或其他第三方插件。这个插件早在 2021 年就停止维护，强行启用反而会和 Composer 2.x 的并发机制冲突，导致内存溢出或 Segmentation fault 错误。
真正起作用的是以下组合：
-
--prefer-dist：强制走预编译包（.zip/.tar.gz），跳过 Git 克隆，这是提速主因 -
--no-interaction --no-progress：砍掉交互提示和 ANSI 进度条输出，在 CI 中尤其省几百毫秒 -
--optimize-autoloader：把 PSR-4 映射转成 classmap，类加载快，但注意：动态拼接类名（如new $className）可能失效
依赖解析慢 ≠ 下载慢，核心在 SAT 求解器 CPU 占用高
当你看到 composer install 卡在 “Resolving dependencies…” 几十秒，不是网络问题，是 Composer 在跑 SAT（布尔可满足性）求解器——它在 src/Composer/DependencyResolver/Solver.php 里暴力尝试所有版本组合，直到找到满足全部约束的解。项目有 300+ 包、composer.lock 超过 8MB 时，PHP 解析 JSON + 构建依赖图 + 回溯剪枝会吃满单核 CPU。
缓解方法很实在：
- 永远提交
composer.lock，避免每次install都重跑求解器 - 删掉没用的
require-dev包（比如只在本地用的phpunit/phpunit放到全局安装，而非项目依赖） - 用
composer why-not some/package查清某个包为何被拉进来，再决定是否剔除
vendor/bin 里的二进制工具不是“加速方案”，而是副作用
有人误以为把 PHPUnit、PHPStan 等工具放进 vendor/bin 就能加速依赖解析——其实完全无关。这些二进制脚本只是 Composer 根据依赖包的 bin 字段自动生成的符号链接（Linux/macOS）或 .bat 文件（Windows），它们本身不参与依赖求解过程。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
但要注意两点：
- 如果你在
composer.json里写了"config": {"bin-dir": "tools"}，它只影响你项目自己声明的bin脚本，对 phpunit、laravel/installer 这类依赖包的二进制文件无效——它们仍硬编码生成到vendor/bin/ - 想让终端直接识别
phpunit，得把./vendor/bin加进PATH，或者统一用composer exec phpunit，后者更可靠且跨平台
真要提速，优先动 lock 文件和镜像源
composer.lock 是性能瓶颈放大器：它存了每个包的完整元数据（dist checksum、source commit、require-dev 列表），大型项目里常超 10MB。解析一个 12MB 的 JSON 文件，PHP 的 json_decode() 就要耗掉 1–2 秒 CPU 时间。
实操建议：
- 定期运行
composer update --lock（不改依赖，只刷新 lock 文件结构），能清理冗余字段 - 用阿里云镜像：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/，国内用户实测下载阶段提速 3–5 倍 - CI 环境中，用
actions/cache缓存~/.composer/cache和vendor/，比反复解析 lock 文件靠谱得多
依赖解析没有银弹。所谓“底层二进制加速”，本质是避开 PHP 层的低效逻辑——要么靠镜像源减少网络等待，要么靠 lock 文件和 classmap 减少 CPU 消耗，而不是指望某个神秘的 C 扩展插件。
