laravel 6 中模型默认不支持构造函数依赖注入，因其由 eloquent 查询器或 new static 直接实例化，未经过服务容器；推荐在方法内按需解析、setter 注入或移至 service 类处理业务逻辑。
在 Laravel 6 中，模型（Eloquent Model）**默认不支持构造函数依赖注入**，这是由框架生命周期决定的：模型实例通常由 Eloquent 查询构造器、`new static` 或反序列化等方式创建，而非通过服务容器解析。因此，直接在模型构造函数中声明依赖（如 `public function __construct(LoggerInterface $logger)`）会导致运行时报错或注入失败。
为什么模型不能像控制器一样自动注入？
因为模型不是由服务容器“管理”的对象。Laravel 的容器只负责解析明确交由它创建的类，比如控制器、命令、事件监听器、服务提供者中绑定的类等。而模型的实例化过程绕过了容器——例如：
-
User::find(1)底层调用new User，非app(User::class) -
$user = new User()是纯 PHP 实例化，容器无感知 - 批量查询返回的模型集合，每个模型都是独立 new 出来的
可行的替代方案（推荐顺序）
虽然不能直接构造注入，但仍有几种安全、实用的方式在模型中使用依赖：
-
在方法内按需解析：使用
app()或$this->app（需继承BaseModel并手动引入容器）获取服务。适用于偶发、非高频调用场景：public function logCreation() {<br> app(LoggerInterface::class)->info('User created', ['id' => $this->id]);<br>} -
通过 setter 注入（显式赋值）：定义 setter 方法，在外部（如控制器或服务类）主动传入依赖：
public function setLogger(LoggerInterface $logger) { $this->logger = $logger; }
然后在控制器中：$user->setLogger(app(LoggerInterface::class)); -
使用访问器/修改器配合服务调用：把依赖逻辑封装进 accessor 或自定义方法，内部调用
app()—— 注意避免在大量模型遍历时频繁解析同一服务，可考虑缓存实例； -
将业务逻辑移出模型：更符合 Laravel 哲学和 SOLID 原则。把需要依赖的服务（如通知、日志、支付）放在 Service 类中，模型只负责数据映射。例如：
class CreateUserAction { public function __construct(UserService $service, Notifier $notifier) { ... } }
模型保持纯净，专注fillable、casts、relations等职责。
不推荐的做法（风险提示）
以下方式看似能“注入”，但存在隐患，应避免：
- 在模型
boot()或静态方法中调用app()：Laravel 6 中容器可能尚未完全启动，尤其在命令行或测试环境下易出错； - 重写模型构造函数并强制走容器（如
return app(static::class)）：破坏 Eloquent 行为，导致关联加载、批量插入等功能异常； - 使用
$this->app->instance()在模型中注册自身：造成容器状态污染，且无法解决构造时依赖缺失的根本问题。
本质上，模型在 Laravel 中定位是“数据载体”，不是服务协调者。依赖注入的最佳实践，是让模型被注入，而不是去注入别人。
