必须按业务动线和复用粒度拆分Service层，如UserOrderService按操作拆为Create/Pay/Refund等trait；校验计算逻辑抽为独立Service或无状态Helper；引入OrderWorkflowService编排流程，避免控制器多处make；依赖请求上下文的Service需动态绑定生命周期。
ThinkPHP Service 层代码臃肿，本质是职责没切开、边界没划清——不是“要不要拆”，而是“必须按业务动线和复用粒度来拆”，否则越加功能越难维护。
Service 类超过 500 行时，优先用 partial class 拆分文件
ThinkPHP 本身不原生支持 partial class（那是 C# 特性），但 PHP 可通过命名空间 + 文件拆分 + 统一接口模拟等效效果。关键不是语法，而是组织逻辑。
- 把一个大
UserOrderService按操作类型拆成：UserOrderService_Create.php、UserOrderService_Pay.php、UserOrderService_Refund.php - 每个文件只定义一个 trait 或一个具体行为类，用相同命名空间，最终在主 Service 中
use这些 trait - 避免直接 new 多个子类再组合；trait 更轻量，且能共享
$this上下文（比如共用$this->orderRepository） - 别把拆分当成“物理隔离”：拆完仍要保证方法调用链清晰，比如
createWithPayment()内部应明确调用$this->doCreate()和$this->triggerPayment()，而不是跨文件隐式跳转
重复校验/计算逻辑，必须抽成独立 Service 或 Helper 类
常见错误是 OrderService 里塞了价格计算、库存预占、优惠券核销三套校验，每次改一个都得通读全类。这类逻辑天然可复用、有明确输入输出，不该绑死在某个 Service 里。
- 价格相关统一走
PricingService::calculate($items, $coupon)，返回完整PriceBreakdown对象 - 库存预占抽成
StockLockService::reserve($skuId, $quantity)，失败直接抛StockNotAvailableException - Helper 类只放纯函数（无状态、无依赖），比如
OrderNumberHelper::generate()；带依赖的必须是 Service，并注册进容器 - 别让 Helper 类偷偷访问
Db::或Cache::—— 那就不是 Helper，是没注册的 Service
控制器里出现多个 app()->make()，说明 Service 职责已溢出
当你在 OrderController 中连续调用 app()->make(OrderService::class)、app()->make(PaymentService::class)、app()->make(NotifyService::class)，其实暴露的是编排缺失：本该由一个更高层的协调者来串联。
立即学习“PHP免费学习笔记（深入）”；
- 引入
OrderWorkflowService：它不处理具体业务，只负责调用顺序、异常兜底、事务包裹（比如createAndPay()包含Db::transaction()） -
OrderService专注订单领域内事（建模、状态流转、关联查询），PaymentService专注支付通道适配，两者都不该知道对方存在 - 别在 Workflow Service 里写 SQL 或渲染视图——它只 return array 或 throw exception
- 如果 Workflow 方法超过 15 行，立刻检查是否混入了本该由下游 Service 承担的逻辑
最常被忽略的一点：拆分后没更新容器绑定策略。比如 StockLockService 依赖当前请求的 tenant_id，但你把它注册为单例，就会在并发请求中互相污染。这种场景下，必须用 app()->bind(StockLockService::class, function ($app) { return new StockLockService($app->make(Request::class)); }); 显式控制生命周期。
