PHP依赖注入容器的核心是通过反射解析构造函数类型提示，递归获取并注入依赖，实现对象自动创建与解耦。它用$bindings存储绑定、make()触发解析、支持单例与闭包绑定，是框架服务管理的底层基础。
要真正理解PHP框架的底层逻辑，必须动手实现一个依赖注入容器——它不是Laravel或ThinkPHP里默认开启的黑盒功能，而是所有现代框架解耦服务、管理对象生命周期的核心机制。
为什么原生PHP项目需要IoC容器
原生PHP写业务时，每个类都自己new依赖，比如User类里直接new Database()、new Logger()。一旦Database连接参数要改，所有用到它的类全得打开修改；想把Logger换成数据库日志，就得逐个替换new FileLogger()为new DbLogger()。这种硬编码依赖让项目越写越脆，改一处崩三处。
IoC容器的作用，就是把“谁来创建对象”这件事从业务代码里抽出来，统一由容器接管。你只声明“我需要一个Logger”，容器自动给你配好——换实现不改一行业务代码。
手动实现一个最小可用IoC容器
方法一：基于反射+构造函数解析的自动注入
立即学习“PHP免费学习笔记（深入）”；
第一步：新建Container.php文件，定义基础结构
声明一个Container类，内部用$bindings数组存储服务绑定规则，用$instances缓存单例实例。这是整个容器的注册中心和记忆中枢。
第二步：实现bind()方法绑定服务
支持两种绑定方式：① 绑定接口到具体实现类（如bind(LoggerInterface::class, FileLogger::class)）；② 绑定闭包（如bind('db', function() { return new PDO($dsn); })）。【闭包绑定必须返回对象实例，否则解析时会报错】
第三步：实现make()方法触发自动解析
调用make(UserService::class)时，容器用PHP反射机制读取UserService构造函数的类型提示，发现它需要LoggerInterface和DatabaseInterface；再递归调用make()获取这两个依赖，最后用ReflectionClass::newInstanceArgs()完成实例化。这一步完全隐藏了new过程。
第四步：增加单例支持
在bind()时加第三个参数true，表示该服务只实例化一次，后续所有make()都返回同一个对象。对数据库连接、配置管理器这类全局共享对象至关重要。
在ThinkPHP中启用并调试依赖注入
ThinkPHP 6+已内置IoC容器，但默认不强制使用。要让控制器自动接收依赖，需两步激活：
① 在app/provider.php中注册服务提供者，例如App\Providers\LogServiceProvider::class，里面完成LoggerInterface到FileLogger的绑定；
② 控制器构造函数参数直接写接口类型：public function __construct(LoggerInterface $logger)。框架会在实例化控制器前，自动从容器取对应实例注入。
【注意：控制器方法不能用public function index(LoggerInterface $logger)这种方式注入，ThinkPHP仅支持构造函数注入】
验证是否生效：在FileLogger的log()方法里打个var_dump('injected')，访问对应路由，看到输出即说明容器已接管依赖创建。
Laravel中IoC容器的典型误用场景
方法一：在服务提供者里错误地new实例
不要在register()方法里写$this->app->instance('cache', new RedisCache())。这会导致RedisCache被提前实例化，即使后续没被用到也浪费连接资源。正确做法是绑定闭包：$this->app->singleton('cache', function ($app) { return new RedisCache($app['redis']); });，延迟到第一次app('cache')才执行。
方法二：混淆bind与singleton
bind()每次make()都新建对象，singleton()保证全局唯一。数据库连接必须用singleton，而请求上下文对象（如Request）必须用bind，否则多个请求共用同一Request实例会串数据。
方法三：在构造函数里调用app()获取依赖
禁止在Service类的__construct()里写$this->db = app('db')。这会让Service强依赖Laravel容器，无法脱离框架单元测试。正确做法是把$db作为构造参数传入，由容器统一注入。
