Composer卡在Resolving dependencies是SAT求解器暴力回溯版本约束所致，非网络或系统死机；此时换镜像、清缓存、调http.timeout均无效，应加-vvv定位卡点，用--dry-run -v识别循环依赖，或通过收缩版本约束、禁用xdebug、提升memory_limit等针对性手段解决。
Composer install 本身不会导致系统“死机”，但依赖升级后卡在某个环节（尤其是高 CPU、内存耗尽、进程僵死）是真实可复现的故障现象。根本原因几乎全是本地求解或执行阶段失控，不是系统级崩溃。
卡在 Resolving dependencies 是 SAT 求解器暴力回溯，不是死机
看到终端停在 Resolving dependencies 不动，CPU 拉满、内存缓慢上涨，说明 Composer 正在本地穷举所有版本组合——它还没发任何 HTTP 请求，http.timeout、换镜像、清缓存全无效。
- 典型诱因：
"symfony/console": "^5.0 || ^6.0"这类宽泛约束，或引入了dev-main私有包导致依赖图爆炸 - PHP 内存不足会触发 OOM Killer 静默杀进程，表现为“突然消失”或
Killed输出，此时需加php -d memory_limit=3G composer install -vvv - 用
composer install --dry-run -v观察末尾是否反复出现同一路径（如vendor/a → vendor/b → vendor/a），这是循环依赖闭环的铁证
卡在 Downloading 却无响应，先验证镜像是否真生效
这一步才真正发 HTTP 请求，http.timeout 才起作用。但很多人配了镜像却没生效，白调超时。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 运行
composer config -g repo.packagist，输出必须是完整 URL（如https://mirrors.aliyun.com/composer/），不能是null或含packagist.org - 项目根目录若存在
repositories字段（哪怕空数组），会直接覆盖全局配置，必须删掉或显式设"packagist.org": false - 手动
curl -I https://mirrors.aliyun.com/composer/packages.json，返回200 OK才算通；若卡住，可能是 IPv6 干扰，临时加环境变量COMPOSER_NO_IPV6=1
卡在 Executing command 是子进程挂起，process-timeout 才管用
日志停在 Executing command (CWD: ...): git clone 或类似命令，说明依赖已解析完，正在跑 post-install 脚本、解压或拉私有 Git 仓库——此时 http.timeout 完全不参与。
- 常见原因：SSH key 未添加进
ssh-agent，git clone卡在密码提示；WSL2 下元数据支持导致 symlink 解析极慢 - 设超时：临时用
COMPOSER_PROCESS_TIMEOUT=1200 composer install，或写入配置composer config -g process-timeout 1200 - 手动执行卡住的命令验证，比如
git ls-remote -h git@github.com:user/repo.git，看是否真卡
Generating autoload files 无响应，问题在文件系统层
这步本质是遍历 vendor/ 写 PHP 文件，不动大概率不是 Composer 逻辑问题，而是底层阻塞。
- WSL2 用户注意：启用元数据支持后，大量 symlink 会导致生成 autoload 极慢；可临时关闭（仅调试）：
wsl --shutdown && wsl -u root sysctl -w fs.protected_regular=0 - 检查
vendor/权限是否混杂（比如部分目录属主为root），修复命令：sudo chown -R $USER:$USER vendor/ composer.lock - APCu 未启用 CLI 模式时，autoload dump 会退化为纯文件扫描，速度骤降；确认
apc.enable_cli=1已开启
真正危险的不是“卡住”，而是你误判环节后乱调参数：在 Resolving dependencies 阶段调 http.timeout，在 Executing command 阶段去换镜像——这些操作不仅无效，还会掩盖真实瓶颈。每一步卡点对应唯一生效的干预手段，错位就等于白忙。
