ThinkPHP 6.0依赖注入需容器解析、类型提示与构造函数签名协同生效；缺一即失效，非黑盒机制。控制器参数能自动注入，因框架用反射读取类型提示并递归调用app()->make()解析，前提是类可自动加载且依赖可被容器解析。
ThinkPHP 6.0 的依赖注入不是“配了就能用”的黑盒机制，而是严格依赖容器解析 + 类型提示 + 构造函数签名三者协同的结果。没绑定、没类型约束、或构造函数参数不可自动解析，注入就直接失效——这不是 bug，是设计前提。
控制器方法里写 UserService 参数为什么能自动注入？
框架在调用控制器方法前，会用反射读取该方法的参数列表，逐个检查类型提示。如果某个参数有明确的类名（如 UserService），容器就会尝试通过 app()->make() 解析它。
- 前提是
UserService类必须可被自动加载（命名空间正确、文件路径符合 PSR-4） - 如果
UserService构造函数还有依赖（比如需要UserRepository），容器会递归解析，直到所有依赖都满足 - 若某一级依赖无法解析（例如类不存在、未绑定接口、或构造函数参数无类型提示），整个链路中断，抛出
ReflectionException或BindingResolutionException
app()->bind() 和 app()->singleton() 有什么实际区别？
两者都往容器注册映射，但生命周期不同：前者每次 make() 都新建实例，后者只创建一次并复用。
- 用
app()->bind('UserServiceInterface', UserService::class)：每次请求UserServiceInterface都 new 一个UserService - 用
app()->singleton('UserServiceInterface', UserService::class)：首次请求创建，后续全走缓存实例 - 接口绑定推荐用
singleton()，避免重复初始化数据库连接、HTTP 客户端等重量级资源
为什么手动 new UserService() 就不走依赖注入？
依赖注入只发生在容器主导的实例化过程中，比如 app()->make(UserService::class)、控制器方法参数、中间件 handle() 方法参数等。手动 new 完全绕过容器，自然不会触发任何解析逻辑。
立即学习“PHP免费学习笔记（深入）”；
- 常见错误：在模型或服务类内部写
new SomeService()，导致无法替换实现、无法 Mock 测试 - 正确做法：把依赖声明为构造函数参数，让容器统一管理；或用
app('SomeService')显式获取 - 注意：
app('SomeService')等价于app()->make('SomeService')，不是全局变量访问
provider.php 里的绑定什么时候生效？
在 App 实例化时就加载并合并进容器的 $bind 数组，属于“启动期绑定”，优先级高于运行时 bind() 调用。
- 默认
provider.php绑定think\Request、think\exception\Handle等核心类，你改写它们就会影响整个请求生命周期 - 如果你在
provider.php里写'UserService' => MyUserService::class，那所有地方用app('UserService')或类型提示都会拿到MyUserService - 覆盖原生绑定要小心：比如把
think\Db换成自定义类，得确保新类完全兼容原有接口
真正容易被忽略的是：依赖注入不是魔法，它高度依赖 PHP 的反射能力和命名空间一致性。哪怕只是拼错一个字母，或者 use 语句漏了，容器就无法定位类——这种错误往往没有明确报错，只表现为参数为 null 或构造函数报错“缺少参数”，排查时得从反射源头一层层查起。
