卡在 resolving dependencies 是 sat 求解器暴力回溯导致的逻辑问题，非网络故障；卡在 downloading 才是 http 层超时，需调 http.timeout；卡在 executing command 则属子进程挂起，应设 composer_process_timeout。
Composer命令没反应，不是“慢”，而是卡在某个具体环节——不看 -vvv 输出，盲目清缓存、换镜像或调超时，基本白忙。
卡在 Resolving dependencies 是 SAT 求解器卡死，不是网络问题
这一行出现后长时间不动，CPU 持续拉高、内存缓慢上涨，说明 Composer 正在暴力回溯所有版本组合。它根本没发 HTTP 请求，http.timeout 完全无效。
- 常见诱因：多个包 require 同一依赖的不同大版本（如
symfony/console^5 和 ^6 并存）、用了dev-main或*这类模糊约束、私有包引入循环依赖 - 快速确认：运行
composer update --dry-run -v，盯最后几行是否反复出现同一组包名嵌套（如vendor/a → vendor/b → vendor/a） - 临时缓解：删掉
require-dev里的非核心工具（如phpstan/phpstan、infection/infection），再试；或加--no-dev跳过开发依赖解析 - 注意：autoload 配置太宽（比如扫描了整个
tests/或examples/）也会拖慢求解——检查vendor/composer/autoload_classmap.php是否超过 2MB
卡在 Downloading https://… 是 HTTP 层失败，http.timeout 才管用
终端停在这一步，且后续无输出或报 cURL error 28、SSL operation failed，说明请求发出去了但没等到响应。此时 process-timeout 不参与，调它没意义。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 先手动验证镜像：运行
curl -I https://mirrors.aliyun.com/composer/packages.json，看是否返回200 OK；若卡在Resolving host，是 DNS 问题；卡在TLS handshake，可能是 OpenSSL 版本太老或企业代理证书未导入 - 设对位置：
composer config -g http.timeout 600（全局）或COMPOSER_HTTP_TIMEOUT=600 composer install（临时，推荐） - 别忽略 PHP 自身限制：运行
php -i | grep default_socket_timeout，CLI 模式下若为 60，可临时绕过：php -d default_socket_timeout=600 $(which composer) install - 阿里云当前稳定地址是
https://mirrors.aliyun.com/composer/，不是/packages.json结尾；腾讯云推荐用https://packagist.proxy.tencent.com/
卡在 Executing command 是子进程挂住，process-timeout 或环境变量才起效
看到日志停在类似 Executing command (CWD: /path): git clone ... 或报 [RuntimeException] The process timed out，说明包已下载完成，正在执行脚本、解压或 git clone 私有仓库。
- 新版 Composer 已不读取
composer config -g process-timeout，必须用环境变量：COMPOSER_PROCESS_TIMEOUT=1200（Linux/macOS）或系统级 Windows 环境变量 - 常见卡点：私有 Git 仓库认证失败（SSH key 未加载、HTTPS 凭据过期）、WSL2 下 symlink 解析慢、APCu 未启用 CLI 模式、
vendor/权限异常 - 调试技巧：加
-vvv后重定向日志：composer update -vvv 2>&1 | tee debug.log，再grep -i "error\|exception\|failed\|zlib\|SAT" debug.log快速聚焦 - 注意：如果
-vvv压根不输出，先查config.verbose是否被设为false，或config.platform里写了不存在的扩展（如"ext-foobar": "1.0"）导致提前退出
-vvv 日志不显示或被截断，很多错误根本看不到
默认的 -v 或 -vv 只显示表层动作，真正卡死的地方——比如 SAT 求解器陷入回溯风暴、gzip 解码失败、插件抛出未捕获异常、cURL SSL 校验被静默中断——统统不会出现。
-
-vvv才会打印：完整 cURL 请求头与原始响应体（含未解压 JSON）、SAT 求解器每一步排除了哪个版本、临时文件路径、插件堆栈、扩展缺失提示（如ext-foobar在config.platform里写了但没装） - 如果
-vvv不输出，优先排查三件事：config.verbose被设为false；config.platform里写了不存在的扩展；Xdebug 干扰（加COMPOSER_DISABLE_XDEBUG=1再试） - 脚本执行失败只显示
Script failed？因为 Composer 默认吞掉 stderr。必须用-vvv才能看到真实错误，比如Fatal error: Uncaught Error:或ParseError - Windows 下 cmd 可能截断树输出，换 PowerShell 或加
| more；composer depends --tree必须有有效的composer.lock才能实锤闭环链
最常被忽略的其实是卡点类型和参数作用域的错配——Resolving 是逻辑问题，Downloading 是 HTTP 问题，Executing 是子进程问题，每个环节对应的参数、排查手段和修复路径完全不同。盯着 -vvv 最后几行，比任何经验都管用。
