laravel 6服务容器通过反射+类型提示+缓存控制自动递归解析多级依赖，核心是安全无环地构建依赖图谱；从make()触发，依次查单例、绑定、反射构造函数参数，遇接口则查bindings，标量需显式绑定，循环依赖靠$buildstack防护。
Laravel 6 的服务容器递归解析多级依赖，靠的是反射（Reflection）+ 类型提示 + 缓存控制，不是一层层“手动展开”，而是自动构建依赖图谱后按需实例化。核心不在“递归”本身，而在“如何安全、无环、可缓存地完成整个依赖链的构造”。
依赖解析从 make() 开始触发
当你调用 app()->make(UserController::class)，容器不会直接 new，而是启动解析流程：
- 先查
$instances数组：这个类是否已被注册为单例？有则直接返回 - 再查
$bindings：是否有显式绑定（比如接口绑定到实现）？有则取绑定的目标类 - 若无绑定，就以
UserController为 concrete 类，进入build()方法
build() 用反射读构造函数，逐个解析参数类型
假设 UserController 构造函数是：
public function __construct(UserService $service, LoggerInterface $logger)
容器会用 new \ReflectionClass(UserController::class) 获取其构造器，再遍历每个参数：
-
$service是UserService类型提示 → 调用$this->make(UserService::class)递归解析 -
$logger是LoggerInterface类型提示 → 查$bindings，发现已绑定LoggerInterface::class => MonologLogger::class→ 再调用$this->make(MonologLogger::class)
注意：每次 make() 都重新走一遍“查缓存 → 查绑定 → build → 反射参数”，形成自然递归调用栈。
递归终止条件与循环依赖防护
容器在解析开始前会把当前抽象（如 UserService）标记为“正在解析中”，写入一个内部数组（$buildStack 或类似状态位）：
- 如果在解析
UserService过程中，又遇到要make(UserService::class)，就立刻抛出BindingResolutionException，防止死循环 - 一旦某类完成实例化，就从
$buildStack移除，并可能存入$instances（如果是 singleton）或直接返回（bind） - 标量参数（如
string $prefix）无法被自动解析，必须显式绑定闭包或使用contextual binding
一个三级依赖的实际例子
假设：
-
ReportController依赖ReportGenerator -
ReportGenerator依赖DatabaseConnection和CacheManager -
CacheManager依赖RedisClient
执行 app()->make(ReportController::class) 时，实际调用顺序是：
每一层都只负责自己构造函数里的类型提示，不关心上层或下层，解耦清晰。只要所有类都有完整类型提示、没有未绑定的接口、没有循环引用，整个链就自动跑通。
