php依赖注入不是语法糖，其本质是将对象创建权交由容器管理；常见问题包括构造函数未被容器调用、接口未绑定实现、命名空间不匹配、thinkphp控制器中__construct无效而需用initialize()、方法参数注入仅限动作方法、singleton()与make()混用导致单例失效等。
PHP 依赖注入不是语法糖，也不是框架专属功能；它本质是把 new 的控制权交出去——谁来创建对象、用哪个实现、生命周期怎么管，都不再由业务类自己决定。
构造函数参数类型提示失效，为什么容器没自动注入？
常见错误现象：写了 public function __construct(LoggerInterface $logger)，但运行时报 ArgumentCountError 或属性为 null。这不是 PHP 解析失败，而是容器压根没参与实例化。
- 确认类是否被容器接管：TP/Laravel 等框架中，控制器/服务必须通过
app()->make()或路由自动解析才能触发注入；直接new UserController()绕过了整个 DI 流程 - 接口必须显式绑定：
LoggerInterface是接口，反射只能读到类型名，无法猜出该用FileLogger还是DbLogger；不调用$container->bind(LoggerInterface::class, FileLogger::class)，容器就无从下手 - 命名空间与文件路径必须严格匹配：
class_exists('app\service\UserService')返回false，容器连反射都不会执行；Linux 下userservice.php≠UserService.php，且需运行composer dump-autoload刷新映射
__construct 在 ThinkPHP 控制器里写了等于白写
ThinkPHP 不会用 new 实例化控制器，而是走 Container::invoke() + 反射，但前提是类被识别为“可管理对象”。手写 __construct 不会被调用，参数不传、逻辑跳过、依赖全空。
- 删掉控制器里的
__construct，改用initialize()—— 这是框架硬编码的统一初始化入口 -
initialize()里不要手动app()->make()，否则绕过容器、破坏可测试性；真正需要依赖时，应改用「方法参数注入」 - 方法参数注入只在控制器动作方法（如
index()、save()）中有效，且参数类型必须已在容器中注册（如think\Request或已bind的自定义类）
singleton() 和 make() 混用导致单例失效
App::singleton() 是声明生命周期策略，App::make() 是按需创建实例。两者语义冲突，混用会让容器行为不可预测。
- 注册时用了
singleton()，但获取时用make()：容器会忽略单例声明，每次新建实例，甚至可能重复解析整条依赖链 - 注册闭包时若内部调用了
$app->make()，而该依赖本身又是singleton()，容易引发递归或状态错乱 - 稳妥做法：统一用
singleton()注册，获取时也优先用app()->get()或类型提示注入；避免在绑定闭包里手动make未声明的类
依赖注入真正的复杂点不在写法，而在边界——接口是否绑定、类是否被容器加载、生命周期策略是否一致。这些地方一松动，问题就藏得深，报错还静默。别假设“写了类型提示就会自动工作”，每个环节都得亲手验证。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
