解读

在国内 PHP 面试中，面试官问“Command 的三种依赖注入方式”通常不是考 Linux 命令，而是考 Laravel 框架里 Artisan Command 的依赖注入写法。Laravel 从 5.5 开始全面支持构造函数注入、handle 方法注入以及可选的 call 方法注入，三种方式各有使用场景和性能差异。能否准确说出三种写法、运行原理以及优缺点，是区分“只会写脚本”与“真正懂框架”的关键。

知识点

1. 构造函数注入（Constructor Injection）

   • 利用 Laravel 容器在实例化 Command 时自动解析依赖
   • 依赖在 Command 整个生命周期内只实例化一次，适合注入 Repository、Service 等无状态对象
   • 必须配合 parent::__construct()，否则会导致 Application 容器无法初始化 Command 基类

2. handle 方法注入（Method Injection）

   • Laravel 在调用 handle() 时通过容器自动解析形参
   • 依赖仅在真正执行命令时才实例化，延迟加载，节省内存
   • 支持注入当前命令用得到的短生命周期对象，如临时 Service、DTO、甚至别的 Command
   • 如果命令被调度器或队列重复调用，每次都会重新解析，避免单例污染

3. call 方法注入（call / IoC 显式解析）

   • 在 handle() 里主动调用 app()->make() 或 resolve() 获取依赖
   • 不属于框架自动注入，但国内很多老项目为了兼容 Lumen 或 Swoole 协程环境会采用
   • 可以动态传参，适合做条件化注入；缺点是失去类型提示与静态分析优势，单测需要手动 mock

答案

“在 Laravel 中，Command 的依赖注入有三种主流方式：

第一种是构造函数注入。在 Command 的 __construct() 里声明依赖，Laravel 容器会在创建命令对象时自动解析。适合注入全局服务，生命周期与命令对象一致，注意必须调用 parent::__construct()。

第二种是 handle 方法注入。把依赖写在 handle(Dependency $dep) 的形参里，框架在真正执行命令时才解析，延迟加载，内存友好，也能避免构造函数里依赖过多导致的臃肿。

第三种是 call 方法注入，即在 handle() 里用 app(Dependency::class) 或 resolve() 手动解析。这种方式最灵活，可在运行时根据条件决定是否实例化，但失去了自动注入的可读性和可测试性，国内一些老代码或 Swoole 协程场景下会见到。

三种方式可以混用，但优先顺序推荐：handle 注入 > 构造注入 > call 注入，既保证性能，又利于单元测试。”

拓展思考

1. 当命令被放入队列时，handle 方法注入的依赖会在队列进程里重新解析；而构造函数注入的依赖在序列化时会被丢弃，因此要避免在构造函数里注入不可序列化的对象（如连接资源）。
2. 如果项目使用 Swoole 协程常驻内存，构造函数注入会导致依赖常驻，可能引发协程间数据污染；此时应改用 handle 注入或 call 注入，并配合连接池的“每次请求重新解析”策略。
3. 单元测试时，handle 注入最容易 mock：只需 $this->app->instance(Service::class, Mockery::mock()) 即可；而 call 注入需要替换全局容器，测试成本最高。
4. 国内很多公司把 Command 当成定时任务入口，建议统一在 schedule() 里用 ->withoutOverlapping() 和 ->onOneServer()，再结合 handle 注入，既保证高并发安全，又节省内存。