laravel 6 容器不支持构造函数循环依赖，必须改用方法注入、接口绑定或运行时app()/resolve()获取实例；强行构造注入会抛出reflectionexception或target [a] is not instantiable。
直接说结论：Laravel 6 中的循环依赖报错，class A depends on class B, and class B depends on class A，不是靠“延迟解析”就能绕过去的——Laravel 容器本身不支持构造函数级的循环依赖，强行写会导致 ReflectionException 或 Target [A] is not instantiable。所谓“延迟解析”，本质是避开构造函数注入，改用方法注入、接口解耦或运行时取实例。
为什么 Laravel 6 容器拒绝构造函数循环依赖
Laravel 6 的服务容器基于 PHP 的反射机制构建，在解析 A::__construct(B $b) 时，会立即尝试解析 B；而若 B::__construct(A $a) 同时存在，容器在递归中无法完成任一实例化，直接抛出异常。这不是配置问题，是设计限制。
-
ReflectionException：“Class A does not exist” 或 “Cannot resolve dependency” 是最常见表现 - 即使两个类都已声明、自动加载正常，只要构造函数互相类型提示，容器就会卡死
-
app()->make(A::class)和路由自动注入都会触发该问题，无例外
真正可用的延迟解析替代方案
所谓“延迟”，是指把依赖的获取时机从对象创建时（构造函数）推迟到实际使用时（方法内）。这不是 Laravel 特有功能，而是手动规避容器限制的实践：
- 把
B从A的构造函数移出，改为在需要时调用$this->app->make(B::class)或app(B::class) - 更推荐方式：在方法参数中注入，例如
public function handle(SomeService $service)—— Laravel 支持方法级自动解析，且不参与构造阶段的依赖图构建 - 若
B本身也需A，不要在B构造函数里再要A，改用$this->resolve(A::class)（仅限控制器等由容器管理的类） - 注意：
$this->resolve()要求当前对象必须由容器创建，否则$this->container为null
接口 + 绑定才是治本之策
延迟解析只是临时止痛，长期维护必须解耦。Laravel 6 完全支持接口绑定，这是官方推荐的解循环标准做法：
- 定义接口
interface PaymentProcessor，让A和B都只依赖该接口，而非彼此具体类 - 在
AppServiceProvider::register()中绑定：$this->app->bind(PaymentProcessor::class, StripeProcessor::class) - 此时
A构造函数写public function __construct(PaymentProcessor $processor)，B同理，循环即破 - 绑定后务必测试：
php artisan tinker→app(PaymentProcessor::class)看是否返回实例
容易被忽略的关键点
很多人试过 app() 或 resolve() 还是报错，往往卡在这几个细节上：
- 在非容器管理的类（如普通工具类、事件监听器里手写
new A()）中调用app()，看似“延迟”了，但A自身构造函数仍含循环依赖，一实例化就崩 - 用了
app(B::class)，但B的构造函数里又写了new A()—— 手动 new 永远绕不过容器，也永远触发原始问题 -
config/app.php的providers数组里注册了相互依赖的服务提供者，这比类级循环更隐蔽，需逐个检查register()方法里的$this->app->make()调用
