Controller 应仅协调请求与响应，业务逻辑须抽离至 Service 或 Action；Service 需无 HTTP 依赖、类型提示构造参数、方法接收 DTO、命名动词开头；异步耗时操作用 QueueableAction；重构前先解决 N+1 查询问题。
控制器里业务逻辑太多，直接导致测试难、改一处崩一片、新人看不懂——这不是风格问题，是架构失衡的明确信号。
Controller 本该只做三件事
它不是业务逻辑容器，而是请求与响应之间的协调者。Laravel 源码里 Controller 基类本身不处理任何业务，只提供生命周期钩子和依赖注入入口。你写的每个 store 或 update 方法，如果超过 10 行且含数据库操作、条件分支、外部调用，就已越界。
- 接收并验证请求 → 交给
FormRequest - 判断用户能否执行 → 交给
Policy或Gate - 执行核心动作（创建订单、扣库存、发通知）→ 必须抽到
Service或Action - 组装响应数据 → 可用
Resource或简单数组，别在 Controller 里拼 JSON 结构
Service 类怎么写才不踩坑
Service 不是“把 Controller 代码剪下来贴过去”的中转站。它得能脱离 HTTP 上下文独立运行，否则还是假解耦。
- 构造函数参数必须全是类型提示的依赖，比如
OrderRepository、PaymentGateway，不能接收Request对象 - 方法参数应为纯数组或 DTO（如
CreateOrderDto），避免绑定框架契约 - 不要在 Service 里调用
redirect()、response()或访问session()—— 这些属于 Controller 职责 - 命名要动词开头：
CreateOrderService、SendWelcomeEmailService，而不是笼统的OrderService
示例：CreateOrderService::__invoke(array $data) 接收订单数据，返回 Order 实例；Controller 只负责把 $request->validated() 传进去，再包一层 response()->json($order)。
什么时候该用 QueueableAction 而不是 Service
当这个业务逻辑天然需要异步、可重试、带失败回调，或者要和其他动作编排成流程（比如“支付成功 → 扣库存 → 发物流单 → 推送消息”），就别硬塞进普通 Service。
-
spatie/laravel-queueable-action提供的QueueableActiontrait 让类既能同步调用（new ProcessOrderAction(...)->execute(...)），也能推入队列（ProcessOrderAction::dispatch(...)） - 它自动支持 Laravel 队列的重试、延迟、超时等机制，而普通 Service +
dispatch(new Job(...))需要额外封装 - Action 类里仍需保持无 HTTP 依赖，但可以自然持有
Job相关上下文（如$this->job->attempts()）
别为了“看起来高级”而加队列 —— 如果逻辑执行时间稳定在 50ms 内，同步更可靠；只有真正耗时或外部依赖不稳定（如第三方 API、邮件网关）才值得异步化。
最容易被忽略的重构前提
抽离逻辑前，先确认你的模型关系是否已预加载。很多所谓“业务逻辑重”，其实是 N+1 查询撑出来的假重量：一个 foreach ($orders as $order) 里反复访问 $order->user->profile->avatar，100 条订单触发 300 次查询，比把 20 行 PHP 逻辑放进 Controller 危害更大。
用 \DB::enableQueryLog() 或 Laravel Debugbar 看清真实 SQL 数量，再动手拆 Service —— 否则你优化了职责划分，却放任数据库拖垮整个链路。
