laravel依赖注入依赖php反射机制实现：通过reflectionclass解析构造函数参数并递归resolve，需类型提示且类非final/abstract；方法注入则用reflectionmethod；反射结果与实例均被缓存以优化性能。
Laravel 的依赖注入不是魔法，它完全靠 PHP 的 ReflectionClass 和 ReflectionParameter 运行 —— 没有反射，app()->make() 就会直接报错。
为什么 app()->make(UserService::class) 能自动构造出对象？
因为 Laravel 在底层调用了 ReflectionClass 解析类结构：先检查类是否可实例化（isInstantiable()），再获取其构造函数（getConstructor()），最后遍历每个参数（getParameters()）逐个 resolve。如果某个参数类型是 UserRepository，就递归调用 make(UserRepository::class)；如果是基础类型（如 string、int）且没设默认值，就会抛出 BindingResolutionException。
关键点：
- 构造函数必须有明确的类型提示（
UserRepository $repo），否则反射拿不到类名，无法继续 resolve - 类不能是 final 或 abstract，否则
isInstantiable()返回 false - 如果构造函数参数带默认值（
int $limit = 10），反射能通过isDefaultValueAvailable()和getDefaultValue()提取，不依赖容器绑定
resolveClassMethodDependencies 怎么处理控制器方法里的 Request？
这个方法在 ControllerDispatcher.php 里，它用的是 ReflectionMethod，不是 ReflectionClass。它只关心当前方法签名，比如 store(Request $request, Validator $validator)，然后对每个 ReflectionParameter 执行 getClass() 获取类型，再交给容器 make()。
注意区别：
- 构造函数注入走的是服务容器的
build()流程，全程由ReflectionClass驱动 - 方法参数注入走的是路由分发时的
resolveClassMethodDependencies()，用ReflectionMethod提取参数类型，再委托给容器 -
Request能被自动解析，是因为框架提前绑定了Illuminate\Http\Request到容器（通常在HttpServiceProvider中），不是靠“猜测”或全局变量
自定义类没被自动注入？先查这三件事
常见错误不是代码写错，而是反射链断在了某处：
- 类文件没被自动加载 ——
composer dump-autoload没跑，或命名空间/文件路径不匹配，导致new ReflectionClass('App\Services\Xxx')直接抛ReflectionException - 构造函数参数用了 PHP 8 的联合类型（
string|int $id）但没设默认值 ——getClass()返回 null，容器无法识别该参数应如何 resolve - 类里用了
__construct但没加public访问修饰符 ——getConstructor()返回 null，容器误判为“无构造函数”，跳过依赖解析，直接new $class，结果因缺少依赖而运行时报错
性能影响：每次请求都走反射，会不会慢？
会，但 Laravel 做了两层缓存：
- 第一次解析后，
ReflectionClass实例和参数元信息会被缓存在容器的$reflectorCache属性中（键为类名） - 对于已绑定的单例（
singleton()），实例本身也被缓存，后续make()直接返回，完全绕过反射 - 真正耗时的是首次加载和解析，不是每次请求 —— 所以开发环境明显变慢，生产环境开启 OPcache 后几乎无感
真正容易被忽略的是：如果你在循环里频繁调用 app()->make(SomeClass::class)，即使类已缓存，反射对象查找 + 参数数组重建仍有开销；这种场景应该改用构造函数注入或提前 resolve 并复用实例。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
