答案是查看 vendor/composer/autoload_psr4.php 和 autoload_classmap.php 文件内容，确认目标命名空间或类是否已注册；若无对应条目，说明未声明或未执行 composer dump-autoload。
直接看 vendor/composer/autoload_psr4.php 和 autoload_classmap.php
Composer 的实际加载规则，最终都固化在 vendor/composer/ 下的 PHP 映射文件里，不是靠实时解析 composer.json。运行过 composer dump-autoload 后，这些文件才被生成或更新。
-
autoload_psr4.php存的是 PSR-4 前缀到路径的数组，键是带反斜杠的命名空间前缀（如"App\"），值是对应目录绝对路径 -
autoload_classmap.php是类名到文件路径的完整映射表，适用于 classmap 或旧包 - 如果类没加载成功，优先打开这两个文件查有没有对应条目；没有，说明没被声明或没执行 dump
用 composer show -s 查包的 autoload 字段来源
想确认某个第三方包（比如 guzzlehttp/guzzle）自己声明了哪些 autoload 规则，不能只看自己项目的 composer.json —— 它的规则在包自己的 composer.json 里。
- 先运行
composer show -s guzzlehttp/guzzle，拿到它在vendor/下的实际路径 - 再进到那个路径，
cat composer.json | grep -A 5 "autoload"，直接看autoload或autoload-dev字段 - 注意：这个字段必须在包的
composer.json顶层，嵌套在extra或scripts里会被完全忽略
为什么 dump-autoload -v 的输出比配置更重要
composer dump-autoload -v 不只是“重新生成”，它的终端输出能告诉你当前生效的是哪套规则、是否命中了你改的配置。
- 如果看到
PSR-4 mapping: ["App\" => "src/"]，说明你的psr-4配置已识别并生效 - 如果只看到
Generating optimized autoload files却没列 PSR-4 条目，大概率是composer.json里autoload写错层级，或拼写错误（比如写成autoloader） - 加
-o参数会跳过 PSR-4 动态匹配，直接走 classmap，这时autoload_psr4.php为空——不是 bug，是优化行为
autoload-dev 配置不会自动进主加载器，得单独验证
autoload-dev 的内容默认不参与日常请求的自动加载，只在你显式运行测试或调用 composer dump-autoload 时才会写入映射文件——但即使写入了，也不会被 vendor/autoload.php 加载，除非你额外 require。
- 验证是否生效：运行
composer dump-autoload后，检查vendor/composer/autoload_psr4.php里有没有你autoload-dev声明的前缀 - 常见误操作：把
tests/bootstrap.php放进autoload-dev.files，但它没 class/interface 声明，Composer 就不扫描也不加载 - 真正要让测试类可用，得确保
tests/TestCase.php以namespace Tests;开头，且路径和"Tests\" => "tests/"完全匹配
真正容易被忽略的是：autoload 规则从不“热生效”。改完 composer.json，不跑 dump-autoload，就等于没改；跑完不检查输出或映射文件，就等于不确定改对了没有。
