记录laravel orm trait加载小技巧

实际业务场景里面不建议这样用，原因在于 auth() 是根据请求鉴权结果获取的数据，以下3种情况无法通过 auth() 获取授准确的权信息：

1. 未授权请求；
2. 队列任务中；
3. 定时任务调度或命令行执行；

所以这样做并不能稳定获取授权信息，我们这样处理以上问题：

1. 业务逻辑层单独封装；
2. 控制器将授权用户ID传入业务逻辑层方法；
3. 队列任务负载数据中保存发起用户的ID；
4. 命令行或任务调度有关联的用户数据，或默认执行的系统用户；

至于 trait 在模型方面的用法，确实有很多可发挥的余地，比如公共的模型关系：

// 存在创建用户的都可以通过这个特性获取该模型关系
trait HasCreatedBy {
    // 只封装这一个方法，因为有些模型可能没有更新用户，这样可以增加适配性
    public function createdBy (): BelongsTo
    {
        return $this->belongsTo(User::class, 'created_by');
    }
    // 增加一个本地作用域 byCreatorId($userId) 方法用来根据创建用户ID查询本模型数据
    public function scopeByCreatorId (Builder $query, int $userId)
    {
        $query->whereHas('createdBy', fn ($query) => $query->where('id',$userId));
    }
}

类似的场景还比如有，是否关联品类 或 三级行政区 等等。

其实创建时间和更新时间框架会自动维护的， 如果是字段和框架默认的 created_at 不同，那只需要在模型中修改 CREATED_AT 和 UPDATED_AT 的值即可。

并不实用，也不推荐这种做法trait 的作用是实现代码复用，而不是逻辑复用，created_by 字段还是推荐在控制器注入，observer也不适合这个例子，observer适合一些事件，比如创建用户同步创建用户扩展，修改用户同步修改用户扩展

挺好