加 -vvv 才能看到真正致命错误的源头，因默认或 -v/-vv 模式会静默吞掉 fatal error，仅 -vvv 模式强制输出完整 stderr 和堆栈起点，暴露 class not found、parseerror、缺失扩展等真实错误。
加 -vvv 才能看到真正致命错误的源头
绝大多数“Fatal error”类报错在默认或 -v/-vv 模式下是被静默吞掉的，你只会看到 Script terminated with exit code 255 或 PHP Fatal error 一行就断了。只有 composer update -vvv（或 install、dump-autoload 等）会强制输出完整 stderr 和堆栈起点。
常见真实错误只在 -vvv 下暴露：
-
Fatal error: Uncaught Error: Class 'FooBar' not found—— 出现在脚本执行中，而非自动加载阶段 -
ParseError: syntax error, unexpected '}'—— 某个.php文件语法错误，dump-autoload -v会卡在它上面 -
ext-foobar is required but missing——config.platform声明了未安装扩展，-vvv会在初始化阶段立刻报错退出
composer dump-autoload -v 是诊断自动加载失败的第一步
当 Class not found 报错出现，别急着改代码或重装包，先运行 composer dump-autoload -v。它会逐行打印扫描行为，告诉你：
- 是否识别了你的 PSR-4 前缀（比如
"App\": "src/"），注意末尾必须有反斜杠"App\" - 是否跳过了某个文件（如含 BOM、短标签、
.php.bak），并明确提示Parse error on line X - 是否根本没进入你预期的目录（说明路径写成了
./src/或拼写错误）
如果输出里完全没出现你的命名空间，问题一定出在 composer.json 的 autoload 区块格式上：漏逗号、多逗号、缩进非法、路径用了相对写法。
检查 vendor/composer/autoload_psr4.php 看最终映射是否正确
这个文件不是缓存，是 Composer 自动加载器实际读取的真相。打开它，搜索你的命名空间前缀（如 "App"），确认映射的物理路径是你项目里的真实绝对路径（如 /var/www/myapp/src/）。再搜具体类名（如 "AppControllersHomeController"），看对应路径是否存在、大小写是否一致、斜杠方向是否为正斜杠。
PSR-4 映射失败的典型陷阱：
- 配置了
"MyApp\": "app/"，但类文件放在app/MyApp/Http/Controllers/HomeController.php—— 多了一层MyApp/，PSR-4 会截掉前缀后去拼Http/Controllers/HomeController.php，结果去找app/Http/Controllers/HomeController.php - 路径末尾少写了反斜杠：
"App"≠"App\"，前者不被识别为有效 PSR-4 前缀
COMPOSER_DISABLE_XDEBUG=1 必须加在 -vvv 前面
Xdebug 会干扰 Composer 的异常捕获和堆栈输出，尤其在 -vvv 模式下可能导致关键错误被截断或掩盖。直接运行：
COMPOSER_DISABLE_XDEBUG=1 composer update -vvv 2>&1 | tee debug.log
然后用 grep -i "fatal|error|exception|zlib|SAT" debug.log 快速定位。别依赖终端滚动回溯——日志重定向才是唯一可靠方式。
真正卡死的地方往往不在网络或权限，而在 SAT 求解器逻辑回溯、gzip 流损坏、或插件未捕获异常；这些只有 -vvv 配合禁用 Xdebug 才能稳定复现。
