Service类需手动获取Model实例，推荐构造函数传入或model()助手函数；TP6废弃D()/M()，须用model('User')或完整命名空间；边界上Model专注CURD与验证，Service负责业务编排与事务。
Service类里怎么拿到Model实例
ThinkPHP 的 Service 层本身不自动注入 Model，它只是普通 PHP 类，没有容器自动解析依赖的机制（除非你手动配置了依赖注入容器并注册了绑定）。所以“注入”不是框架默认行为，而是靠你显式调用或构造传入。
- 最直接的方式是：在 Service 方法内部用
model('User')或User::get()等静态方式访问模型 - 更推荐的方式是：通过构造函数传入模型实例，便于单元测试和解耦。例如：
public function __construct(User $user)，然后在控制器中 new Service 时把new User()传进去 - 如果用了 ThinkPHP 6+ 的容器（
think\Container），可以提前绑定：Container::getInstance()->bind('User', User::class)，再在 Service 构造中声明User $user，容器会自动解析——但这需要你主动启用并配置，不是开箱即用
为什么不能直接在Service里用D()或M()方法
D() 和 M() 是 ThinkPHP 5.x 的遗留方法，在 TP6 中已被废弃，调用会报 Call to undefined function D() 错误。TP6 统一使用 model('User') 助手函数或完整命名空间类名（如 \app\model\User）来获取模型实例。
-
model('User')返回的是模型类的实例，等价于new \app\model\User() -
model('user')（小写）也能工作，但建议保持首字母大写以匹配类名规范 - 若模型在子命名空间下（如
\app\service\model\User），需传入完整类名字符串：model('\app\service\model\User')
Service调用Model时容易踩的坑
常见错误不是“注入失败”，而是模型调用时机或上下文错乱，尤其涉及事务、事件、关联查询时。
- 在 Service 中直接调用
User::save()会触发模型事件（如beforeWrite），但事件回调里拿不到请求参数——因为模型事件只传$model，不带Request对象。必须提前把 operator_id、client_ip 这类字段塞进模型属性再保存 - 多个 Service 共享同一个 Model 实例时，要注意模型状态（比如
$user->isUpdate()判断可能因复用而失准） - 跨模型操作（如订单 + 用户 + 商品）不要在单个 Service 里硬编码调用多个 model()，应拆成各自的 Service 封装，再由上层组合调用，否则违反“单一职责”且难以复用
TP6 中 Service 和 Model 的协作边界在哪
Service 不该承担数据映射或字段验证逻辑，这些属于 Model 职责；Model 也不该处理折扣计算、库存扣减策略、第三方接口调用这类业务规则——那是 Service 的地盘。
立即学习“PHP免费学习笔记（深入）”；
- Model 只做三件事：定义表名/主键/验证规则、封装基础 CURD、提供关联定义（
hasMany等） - Service 做三件事：编排多个 Model 或其他 Service 的调用顺序、处理事务边界（
Db::transaction()）、实现含条件分支的业务逻辑（如“满 200 减 30，限新用户”） - 如果某个 Service 方法里反复出现
where()->order()->limit()链式调用，说明这部分应该下沉到 Model 的作用域方法里（如User::recentActive()），而不是堆在 Service 中
