Laravel服务容器通过反射+绑定注册+递归解析三步闭环实现依赖注入：先用ReflectionClass读取构造函数类型提示，再查bindings获取具体实现，对未绑定类直接new，接口则按绑定返回对应实例，单例首次解析后缓存复用。
Laravel 服务容器不是“自动猜出你要什么”的黑箱，它靠的是反射（ReflectionClass）+ 绑定注册 + 递归解析这三步闭环完成依赖注入。没有手动绑定或类型提示，它不会凭空给你实例。
为什么 app(SomeService::class) 能直接返回对象？
因为 Laravel 在启动时已通过服务提供者（如 AppServiceProvider）把常见类默认绑定了——比如 SomeService 没显式绑定，容器就按约定直接 new 出来；如果绑定了接口（如 CacheContract），则返回对应实现（如 FileStore）。
- 未绑定的类：容器用
ReflectionClass读取构造函数参数类型，再对每个参数递归调用resolve() - 已绑定的抽象（如接口）：走
$this->bindings查找 concrete，再解析 concrete - 单例绑定（
singleton()）：首次解析后存进$this->instances，后续直接返回缓存实例
__construct(UserRepository $repo) 是怎么被自动填满的？
路由闭包、控制器方法、事件监听器等 Laravel “可调用位置”都经过 Container::call() 处理。它会提取该 callable 的反射信息，逐个解析形参类型——不是靠注释或配置，而是实打实读 PHP 类型声明。
- 必须是类名或接口名类型提示（
UserRepository），不能是array或string这类标量 - 如果参数有默认值（
int $limit = 10），且无对应绑定，容器跳过它，用默认值 - 如果某依赖本身还有依赖（比如
UserRepository构造函数要DatabaseConnection），容器递归处理，直到叶子节点
手动绑定时 bind() 和 singleton() 有什么实际区别？
只差在是否复用实例。用错会导致状态污染或意外共享，尤其在请求生命周期中操作了对象属性时。
-
bind()：每次app()都新建实例（适合无状态、轻量服务） -
singleton()：首次解析后存进容器，后续全返回同一个对象（适合连接池、全局配置管理器） - 错误示范：
$this->app->bind(LoggerInterface::class, FileLogger::class)—— 每次都要 new 一个日志器，磁盘句柄可能撑爆
什么时候反射会失败，导致 Target class [xxx] does not exist？
不是类不存在，而是容器找不到它该用哪个具体类去构建——常见于接口未绑定、命名空间写错、或自动加载失效。
- 检查是否漏了
use语句，导致类型提示变成当前命名空间下的相对路径 - 运行
composer dump-autoload确保 PSR-4 映射生效 - 接口绑定必须在
register()方法里完成，boot()太晚，解析时 binding 还没注册 - 别在
config/app.php的providers数组里写错类名，会导致服务提供者根本没加载
真正容易被忽略的是：容器只管“怎么造”，不管“何时造”。构造函数里做耗时操作（如连接数据库、读大文件），会在第一次解析时阻塞整个请求——这不是容器的问题，是你把初始化逻辑放错了地方。
