是卡住了，非网络慢而是SAT求解器逻辑卡死；需用-vvv观察是否有“SAT: Excluding”等动作，无则可能死循环或插件中断，应检查config.platform扩展名、禁用Xdebug并用--dry-run过滤线索。
composer update -vvv 日志停在 Resolving dependencies through SAT 是卡住了吗
不是网络慢，是依赖求解器逻辑卡死。SAT 求解过程会逐个尝试版本组合，一旦约束太紧（比如多个包同时要求互斥的 PHP 版本或扩展），它可能回溯几千次后才放弃——而日志里只显示这一行，没进度提示。
关键看 -vvv 输出中这行之后是否还有 SAT: Excluding package/version 或 SAT: Trying package/version 这类动作。没有？说明已陷入死循环或被某个插件中断。
- 先检查
config.platform里有没有写错扩展名，比如"ext-foobar": "1.0"—— Composer 在-vvv下遇到不存在的扩展会直接退出，不继续求解 - 确认没启用 Xdebug：加
COMPOSER_DISABLE_XDEBUG=1再试，否则堆栈可能被截断 - 用
composer update --dry-run -vvv 2>&1 | grep -E "(SAT:|error|exception)"快速过滤核心线索
脚本执行失败只显示 “Script failed”，怎么定位真实错误
Composer 默认把子进程 stderr 吞掉，你看到的只是退出码，不是崩溃原因。
必须用 -vvv，它会原样打印每条脚本命令、完整环境变量、以及该命令退出时的原始 stderr 输出。
- 常见真实错误只在
-vvv下可见：Fatal error: Uncaught Error:、ParseError、Class not found - 如果脚本是 PHP 文件，Linux/macOS 下要检查是否有
#!/usr/bin/env php头和可执行权限；Windows 推荐显式写"php script.php"，避免系统找不到解释器 - 别只盯着最后一行
Script terminated with exit code 255，往上翻 10–20 行，找真正触发它的那条命令及其 stderr
为什么 -v 和 -vv 基本没用，非得 -vvv
-v 只告诉你“正在装什么包”，-vv 多给点 HTTP 状态码或平台检测结果，但真正卡死的地方全看不到。
只有 -vvv 会暴露底层细节：
- 完整 cURL 请求头与原始响应体（含未解压 JSON）
- SAT 求解器每一步排除了哪个版本
- 临时文件路径、插件堆栈、扩展缺失提示（比如
ext-foobar在config.platform里写了但没装） - 看到
zlib_decode(): data error？说明中间代理损坏了压缩流
日志输出太快看不清，怎么可靠捕获
终端滚动太快不是靠眼睛盯，而是重定向到文件最稳。
运行：composer update -vvv 2>&1 | tee debug.log，然后用 grep -i "error\|exception\|failed\|zlib\|SAT" debug.log 快速聚焦关键行。
注意：如果 -vvv 完全没输出，先查三件事：
-
composer config --list | grep verbose看config.verbose是否被设为false（优先级高于命令行参数） -
config.platform里有没有不存在的扩展（会直接报错退出） - 是否被 Xdebug 干扰（加
COMPOSER_DISABLE_XDEBUG=1再试）
复杂点在于：日志本身不是问题，而是你读到哪一行、忽略哪一行，决定了能不能看到真正的断点。很多错误信息就藏在倒数第 15 行，而不是最后一行。
