Composer依赖解析时卡死在Updating？检查网络代理与DNS污染【方法】-composer-PHP中文网

卡在“updating dependencies”是sat求解器暴力回溯导致的依赖冲突死锁，非网络问题；应运行composer why-not定位阻断链，或收窄版本约束、注释require-dev、使用--with-all-dependencies跳过校验。

composer依赖解析时卡死在updating？检查网络代理与dns污染【方法】

卡在 “Updating dependencies” 不等于网络慢，90% 是依赖求解器（SAT）在暴力回溯，和代理、DNS 没关系；真卡在网络层时，实际停在的是 “Resolving dependencies” 或 “Downloading” —— 别被日志误导。

这行输出一出现就长时间不动，说明 Composer 还没发任何 HTTP 请求，只是在查域名、建 TCP 连接、做 TLS 握手。http.timeout 完全无效，改了也没用。

手动验证镜像连通性：curl -I https://mirrors.aliyun.com/composer/packages.json，返回 200 OK 才算通
如果卡在 Resolving host 或 TCP connect，换 DNS（比如 114.114.114.114）或临时加 hosts：121.40.187.156 mirrors.aliyun.com（以当前阿里云 CDN IP 为准）
公司内网常见于中间人代理未导入根证书，-vvv 最后一行若报 error:14090086 就是它，不是超时
确认镜像配置没被覆盖：composer config -g repos.packagist 和项目内 composer config repo.packagist 都要查，还要看 $COMPOSER_REPO_PACKAGIST 环境变量

看到 Downloading https://mirrors.aliyun.com/composer/p/xxx/ 后不动，或反复重试后静默退出，才是真正的 HTTP 层卡顿。此时 process-timeout 无效，必须调 http.timeout。

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

全局设值：composer config -g http.timeout 600（单位秒，300～600 足够）
项目级更安全：composer config http.timeout 600，会写入 composer.json 的 config 段
临时调试优先用环境变量：COMPOSER_HTTP_TIMEOUT=600 composer install
PHP 自身的 default_socket_timeout 也会干扰，可绕过：php -d default_socket_timeout=600 $(which composer) install

这行日志之后无下载、无报错、CPU 占用高、内存缓慢上涨——基本可以确定是依赖约束太宽或冲突太深，SAT 在指数级回溯。清缓存、换镜像、调 timeout 全部无效。

真正拖垮 Composer 的，往往不是配置本身，而是那些“看起来无关”的底层限制：

composer.lock 文件权限异常（尤其 WSL2 或 Docker 中），会导致 autoload 生成卡在最后一步
PHP CLI 模式下 APCu 未启用，Generating autoload files 会慢 3～5 倍
某些 CI 环境硬编码了 packagist.org，覆盖所有镜像设置，得查 composer show -p 看真实生效仓库
私有包用了 SSH Git URL 但没配好 key，Executing command git clone git@xxx 会卡住且不报错，需加 --prefer-dist