Composer install卡在“Resolving dependencies”本质是本地CPU穷举版本组合，宽泛约束（如"^1.0 || ^2.0"）或松散PHP版本要求会导致求解器指数级爆炸；非网络问题，需收紧约束、禁用xdebug、换镜像并清缓存。
Composer 执行慢，90% 不是网络问题，而是本地配置、依赖结构或运行环境没对上。换镜像源只是第一步，不调全局配置、不收紧版本约束、不关冗余功能，速度不会明显提升。
为什么 composer install 卡在 “Resolving dependencies”
这不是在下载，是在本地穷举所有可能的包版本组合——尤其当 composer.json 里写了 "^1.0 || ^2.0" 或 "*" 这类宽泛约束时，求解器会指数级爆炸。
- 用
composer install -v看最后请求的 URL：如果停在packages.json或provider-2023路径，说明卡在元数据拉取，不是解析本身 - 临时验证是否缓存损坏：加
--no-cache再试一次，有时反而更快 - 长期解法：换阿里云镜像 + 显式关闭官方源回退：
composer config -g repos.packagist false（注意不是repo.packagist） - PHP 版本约束太松也会拖慢：
"php": ">=7.4"比"php": "^8.1"多查几百个包的兼容性元数据
为什么 composer update 总是重算整个依赖图
默认行为就是全量重建，哪怕你只改了一个包的版本号。它不会复用 composer.lock 里已验证过的其他包兼容关系。
- 精准更新单个包：
composer update vendor/package-name（不带版本号），其余包版本保持锁定 - 连带升级子依赖？只在明确需要时加
--with-dependencies，多数情况不加更稳更快 - 删掉
"minimum-stability": "dev"—— dev 版本候选集太大，稳定版约束能直接砍掉 80% 的求解时间 - CI/CD 中无条件跑
composer update是反模式；应该用composer install --no-interaction --no-scripts靠 lock 文件保证一致性
composer install 卡在 “Installing dependencies” 怎么办
这个阶段卡住，基本和依赖解析无关，是下载、解压或文件 I/O 出了问题。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 并发下载数默认是 20，对 2GB 内存容器太激进：用
composer config -g parallel-downloads 4限流 - 换镜像后必须清缓存：
composer clear-cache，否则旧包仍走官方源 - 检查是否启用了
opcache.enable_cli=1（PHP 8.2+）—— CLI 场景下它反而拖慢 Composer 自身加载，建议关掉 - 避免在 WSL2、Docker Desktop（macOS/Windows）挂载卷里执行 install；vendor 目录应由命名卷或本地 SSD 托管
容易被忽略但影响巨大的配置项
很多人改完 composer.json 就以为完了，其实真正起效的是全局配置和 CLI 环境。
-
composer config -g cache-dir /path/to/ssd/composer-cache：默认缓存若落在机械盘或加密卷上，解压 ZIP 包会慢 2–5 倍 -
composer config -g discard-changes true：避免 CI 中因交互提示卡住（“Discard changes and run install?”） - 禁用 Xdebug：它会让依赖解析慢 5–10 倍；临时禁用命令是
php -d zend_extension= -d xdebug.mode=off /usr/bin/composer install - 别留着
fxp/composer-asset-plugin—— 它早已废弃，且严重拖慢解析，删掉再试
最常被跳过的一步：确认 COMPOSER_HOME 和 COMPOSER_CACHE_DIR 是否指向可写路径，且不在 NFS 或虚拟机共享目录里。I/O 权限和延迟比网络还难排查。
