-vvv是定位Composer加载异常的唯一有效开关，因其能输出HTTP响应体、SAT求解步骤、插件崩溃行等底层信息，而-v和-vv仅显示表层动作。
为什么-vvv才是定位 Composer 加载异常的唯一有效开关
因为-v和-vv只暴露表层动作，而真正卡住加载的环节——比如 SAT 求解器死循环、gzip 解码失败、插件在 autoload 阶段抛出未捕获异常——只有-vvv会打印。它不是“更多日志”，而是打开底层通道：输出原始 HTTP 响应体、临时文件路径、SAT 每一步排除了哪些版本、甚至插件中哪行 PHP 代码因ext-foobar缺失而崩溃。
常见失效场景：
-
config.verbose被设为false，命令行参数-vvv会被静默忽略 -
config.platform里写了不存在的扩展（如"ext-foobar": "1.0"），-vvv会直接报错退出，根本走不到依赖解析 - Xdebug 启用状态下堆栈被截断，加
COMPOSER_DISABLE_XDEBUG=1再试
实操建议：用composer update -vvv 2>&1 | tee debug.log保存完整输出，再用grep -i "error|exception|zlib|SAT"快速聚焦关键行。特别注意日志开头几行——Reading ./composer.json失败说明 JSON 格式错误，比后面几百行冲突更早暴露根因。
composer dump-autoload -v能暴露 90% 的自动加载配置问题
类找不到，八成不是代码写错，而是 autoloader 映射没生成或没更新。composer dump-autoload -v会逐行打印扫描路径、匹配到的类、跳过的文件，以及 PSR-4 / classmap 是否生效。它比盲目删vendor/或重装快得多。
典型线索：
- 输出里完全没出现你的命名空间前缀 →
composer.jsonautoload 配置未被识别（缩进错、逗号漏、引号不闭合） - 提示
Scanning directory src/但没列任何类 → 文件扩展名不是.php，或目录下没有符合命名空间结构的类文件 - PSR-4 条目末尾缺反斜杠（如
"App": "src"而非"App\": "src/"）→ 映射失效但不报错
注意：dump-autoload -o生成的优化版映射依赖静态快照，开发中频繁改类名/路径时反而容易失效；调试阶段优先用不带-o的版本。
查类到底从哪来？直接读vendor/composer/autoload_psr4.php
Composer 不记录“谁提供了这个类”，它只按规则生成映射表。要定位，必须逆向查 autoload 文件。
操作顺序：
- 先确认
composer dump-autoload -v已成功执行（终端显示Generating optimized autoload files） - 打开
vendor/composer/autoload_psr4.php，找最长匹配前缀：类GuzzleHttpPsr7Request就从GuzzleHttpPsr7开始找（注意末尾反斜杠） - 没匹配上？再查
autoload_classmap.php；连这个也没有，说明该类没被声明 autoload，可能是拼写错误、手动 require，或属于未启用 autoload 的旧包
PSR-4 推导路径是“截掉命名空间前缀后拼剩余部分”。例如配置"MyApp\": "app/"，则MyAppHttpControllersHome对应app/Http/Controllers/Home.php——不是app/MyApp/Http/。大小写也敏感：目录app/配命名空间myapp，一定失败。
PHP 内置服务器下Class not found的隐藏陷阱
php -S不自动加载autoload.php，也不会触发 Composer 的任何初始化逻辑。你写的require 'vendor/autoload.php'如果漏了、位置错了、或者被if包裹跳过，类就直接找不到。
必须检查：
- router.php 第一行是否就是
require __DIR__.'/vendor/autoload.php';（不能在函数里、不能加条件判断） -
composer.json中"psr-4": {"App\": "src/"}，但类文件实际在app/目录下 → 路径与配置不一致 - 启动
php -S的当前工作目录是否是项目根目录？__DIR__会随启动路径变化，路径错就全错
调试期间别用-o模式：它把映射编译进autoload_classmap.php，一旦你移动或重命名类文件，映射就指向旧路径。此时去掉-o，让 PSR-4 动态推导，反而更容易暴露路径配置错误。
