PHP方法依赖注入是构造函数注入的补充而非替代，仅适用于控制器Action等被框架调用的临时、可选或上下文相关依赖，不支持标量、数组及未显式绑定的DTO类，且不可用于业务方法内手动get()。
PHP 方法依赖注入不是构造函数注入的替代方案，而是补充——它只在特定方法需要临时、可选或上下文相关的依赖时才用，不能代替构造函数里声明的必需依赖。
方法参数注入只在控制器 Action 里自动生效
ThinkPHP 6 和 Laravel 等主流框架支持在控制器方法签名中直接写类型提示，框架路由层会自动从容器取实例注入。但这个机制仅限于「被框架调用的方法」，比如 index()、store() 这类 Action 方法。
- 必须确保该类已由容器实例化（TP6 要求控制器继承
think\BaseController，且未手动new） - 只支持容器中已注册的类或框架内置约定类（如
think\Request、think\Validate） - 不支持标量类型（
string、int）、数组、DTO 类（除非你显式绑定并配置自动解析） - 若方法参数是
UserService $service却报错，先检查是否在config/container.php中绑定了'app\Service\UserService' => \app\Service\UserService::class
方法内手动调用 $container->get() 是反模式
在业务方法内部写 $logger = $container->get(LoggerInterface::class) 看似灵活，实则破坏了依赖声明的可见性，让调用方无法预知该方法实际依赖什么。这等于把“硬编码 new”换成了“硬编码 get”，耦合没解，只是藏得更深。
- 测试时无法通过构造或参数控制依赖行为
- 静态分析工具（如 PHPStan）无法识别隐式依赖
- 一旦容器配置变更（如改用 singleton），所有手动
get()的地方都可能出问题 - 真正需要动态获取的场景（如根据条件选不同缓存驱动），应注入工厂接口（
CacheFactoryInterface），而不是容器本身
构造函数注入仍是主力，方法注入只是“补漏”
构造函数注入明确表达了类的刚性依赖，而方法注入只适合那些「每次调用可能不同」或「非必需」的依赖。比如一个导出服务，多数时候用 CSV，但某次请求要导出 Excel —— 这时用方法参数传 ExporterInterface $exporter 比在构造函数里塞两个实现更合理。
立即学习“PHP免费学习笔记（深入）”；
- 构造函数里放
Database $db、LoggerInterface $logger：它们是类运行的基础 - 方法参数放
NotificationChannelInterface $channel、ExportFormat $format：它们随请求上下文变化 - 别为了“看起来能注入”而在构造函数留空，然后全堆到方法参数里——那只是把耦合从一处挪到另一处
- CodeIgniter 4 和 Laravel 的 Service Container 都默认优先尝试构造函数注入；方法注入是额外能力，不是兜底方案
最易被忽略的一点：方法注入依赖的生命周期完全由调用时机决定，它不会被容器缓存（除非你显式设为 singleton 并在方法里重新 get()），这意味着两次相同方法调用可能拿到两个不同的实例——对数据库连接或单例日志器来说，这可能是 bug 而非特性。
