“导出加速”说法错误，因Composer无“导出”动作；卡顿实际发生在install/update等环节，需按Loading repositories（换镜像+clear-cache）、Resolving dependencies（收紧版本约束）、Downloading（验证镜像可用性）或脚本执行四类问题精准定位优化。
为什么“导出加速”这个说法本身就有问题
Composer 没有“导出”这个动作，更不存在“导出加速”一说。你看到的卡顿，基本都发生在 install、update 或 create-project 过程中，本质是依赖解析、元数据加载、包下载或脚本执行四个阶段之一出了问题。把卡顿归因为“导出慢”，会直接错过真正要调优的环节。
卡在 “Loading composer repositories” 怎么办
这行输出不是卡，是 Composer 正在连接所有配置的仓库（尤其是 packagist.org）拉取 packages.json 元数据。国内访问默认源极不稳定，表现为长时间无响应或 0 B/s。
- 必须用正确格式切换镜像：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/—— 键名是repo.packagist（不是repos），composer是 type 值（不能省），URL 末尾必须带/ - 换源后立刻执行
composer clear-cache，否则缓存里旧的元数据会继续走原路径 - 验证是否生效：
composer config -g repo.packagist输出必须是完整 JSON，比如{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}；如果还是https://packagist.org，说明根本没写进去
卡在 “Resolving dependencies” 是网络问题吗
不是。这个阶段完全离线，Composer 在本地穷举满足 composer.json 所有约束的版本组合。越宽松的约束，求解时间呈指数增长。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 检查是否有类似
"php": "^7.4 || ^8.0"或"minimum-stability": "dev"这类宽泛配置 -
"yii2/framework": "*"比"yii2/framework": "~2.0.48"更容易触发依赖爆炸 - 删掉长期不用的
require-dev包，它们不安装，但参与解析 - 运行
composer update --lock可压缩composer.lock文件体积，减少 JSON 解析开销
卡在 Downloading 或 post-install-cmd 怎么破
前者是下载慢或中断，后者是脚本执行阻塞。两者解决逻辑完全不同。
- 下载卡：确认镜像已生效 + 清缓存 + 加超时：
composer config -g process-timeout 600和composer config -g http.timeout 300 - 脚本卡：看
composer.json的scripts，手动运行post-install-cmd里的命令（如php artisan key:generate --no-interaction），确认是否等待输入或权限异常 - CI/CD 中必须加
--no-interaction（等价于-n），否则遇到信任提示会永久挂起 - PHP 配置也要查：
proc_open()被禁用、memory_limit过低、max_execution_time太短，都会让脚本中途退出
真正难调的从来不是某一行命令，而是镜像配错却以为配对了、缓存没清却反复试新命令、把解析卡顿当成网络问题去折腾代理——这些点一旦漏掉一个，所有优化都白搭。
