Composer加载慢导致超时报错，90%非网络问题，而是镜像未配对（repo.packagist拼写、type值、URL末尾/三条件缺一）、缓存路径不合理、依赖约束过宽或xdebug未关闭；需严格验证配置、收紧PHP与稳定性约束、迁移缓存至SSD并禁用xdebug。
Composer 加载慢导致超时报错，90% 不是网络问题，而是镜像没配对、缓存路径不合理、依赖约束太宽或 xdebug 没关——换源只是第一步，不清理旧配置、不收紧约束、不迁缓存目录，速度不会明显提升。
镜像配置为什么总不生效
不是 Composer 没反应，是它静默失败了。三个硬性条件缺一不可：
-
repo.packagist（不是repos.packagist，多一个 s 就彻底忽略） - 第二个参数必须是
composer（这是仓库类型声明，漏掉会 fallback 到官方源） - URL 必须以
https://开头且末尾带/（https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌）
验证是否成功：composer config -g repo.packagist 输出应为 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} 或至少是完整 URL 字符串。如果为空、null 或仍是 https://packagist.org，说明完全没写进去。
卡在“Resolving dependencies”怎么办
这不是下载慢，是本地 CPU 在暴力穷举满足 composer.json 所有约束的版本组合——尤其当写了 "*"、"^1.0 || ^2.0" 或 "minimum-stability": "dev" 时，求解器会指数级爆炸。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 删掉
"minimum-stability": "dev"——稳定版能直接砍掉 80% 的求解时间 - 收紧 PHP 版本约束：
"php": "^8.1"比"php": ">=7.4"少查几百个包的兼容性元数据 - 确保
composer.lock已提交进 Git，并在 CI/部署中始终用composer install（不是update） - 临时禁用 xdebug：
php -d xdebug.mode=off $(which composer) install，它会让解析慢 5–10 倍
缓存目录放错位置会让 install 慢 2–5 倍
默认缓存路径 ~/.composer/cache 若落在机械盘、WSL2 挂载的 Windows 目录、加密卷或 NFS 上，解压 ZIP 包时 I/O 就成瓶颈。
- 查当前生效值：
composer config --global cache-dir - 强制迁移到 SSD 路径：
composer config -g cache-dir /mnt/ssd/composer-cache - 临时测试是否走新路径：
COMPOSER_CACHE_DIR=/tmp/composer-cache composer install --dry-run，再看/tmp/composer-cache下有没有新文件生成 - 缓存目录必须可写，且别挂到低速卷上
http.timeout 和 process-timeout 到底管什么
这两个参数作用层完全不同，混用会导致调了也没用：
-
http.timeout：控制单次 HTTP 请求从 DNS 查询、TCP 连接、TLS 握手到响应头返回的总耗时（单位秒），适用于Could not fetch https://类错误 -
process-timeout：控制整个composer install命令生命周期，包括依赖解析、下载、解压、执行post-install-cmd脚本等，超时直接kill -9
常见错误是看到 cURL error 28: Operation timed out after 300000 milliseconds 还去调 process-timeout——它根本不管 HTTP 层超时，得靠 http.timeout 或换镜像解决。
