laravel 6 依赖解析失败时抛出 bindingresolutionexception 而非 class not found，主因是服务容器无法构建注入链，包括自动加载未配置、标量参数无默认值、接口未绑定实现或依赖链中断。
Laravel 6 的服务容器在解析依赖失败时，通常不会直接抛出“Class not found”这类底层错误，而是通过 BindingResolutionException 包装后抛出，提示类似 Target class [xxx] does not exist 或 Unresolvable dependency resolving [Parameter #0 [ <required> $xxx ]] in class Xxx</required>。根本原因不是类文件缺失，而是容器无法完成依赖注入链的构建。
常见触发未找到依赖异常的场景
这些情况在 Laravel 6 中尤为典型（因其不支持 PHP 8 命名参数、容器解析逻辑较新版本更严格）：
-
类文件未被 Composer 自动加载：比如手动把类放到
app/Services但没在composer.json的"autoload": {"psr-4": {...}}中声明路径，执行composer dump-autoload后仍无效 -
构造函数含标量参数（string/int/bool）且未提供默认值或运行时参数：Laravel 6 容器无法自动猜测字符串内容，
make(SomeService::class)会因无法解析$apiToken这类参数而失败 -
接口未绑定具体实现：例如类型提示了
MailerInterface，但未在AppServiceProvider::register()中调用$this->app->bind(MailerInterface::class, MailerImpl::class) - 依赖链中断：A 依赖 B，B 依赖 C，若 C 的构造函数有未满足的参数或类不存在，容器会在解析 A 时层层报错，最终异常堆栈顶层显示的是 A 的位置，但根因在 C
快速定位依赖解析卡点的方法
不用盲目翻日志，直接在容器解析关键节点加钩子：
- 在
AppServiceProvider::register()中加入调试回调：$this->app->resolving(function ($object, $app) { Log::debug('Resolving: ' . get_class($object)); });
可确认哪些类被成功触发解析，哪些根本没走到 - 临时修改框架源码（仅开发环境）：打开
vendor/laravel/framework/src/Illuminate/Container/Container.php，在resolveDependencies()方法内加dd($dependency->getName());，能直观看到容器正尝试解析哪个参数 - 用
php artisan tinker逐级测试：>> app()->make(YourService::class)—— 看是否立即报错>> app()->make(DependencyClass::class)—— 验证链中上游是否可用
对比 make() 和 resolve() 的行为差异
这个细节在排查时很关键，Laravel 6 中两者处理异常的方式不同：
-
make()：走完整生命周期，包括resolving/resolved回调、单例缓存检查；若中间某步失败，异常信息更完整，但堆栈更深 -
resolve()：跳过所有回调和缓存逻辑，只做纯粹依赖注入；若它能成功而make()报错，说明问题出在回调里（比如某个resolving闭包里写了错误逻辑）
验证自动加载是否生效的实操步骤
很多“找不到类”本质是 PSR-4 映射没生效：
- 运行
composer dump-autoload -o（优化模式），再试make() - 检查
vendor/composer/autoload_psr4.php，确认你的命名空间前缀（如'App\Services\' => array($baseDir . '/app/Services')）已写入 - 用 PHP 命令行直接测试自动加载：
php -r "var_dump(class_exists('AppServicesSomeService'));"—— 返回bool(true)才算类可被加载
