Laravel控制器设计指南：单一职责实践

本文深入阐述了 Laravel 控制器设计的核心原则——坚守单一职责，强调控制器仅作为 HTTP 请求的“守门人”，而非业务逻辑的容器；通过 FormRequest 实现验证逻辑的彻底解耦，利用 Service 类封装事务处理、邮件发送、角色分配等复杂操作，剥离非 HTTP 相关代码（如文件存储、HTTP 调用），并消除控制器内方法间因依赖 Request 对象导致的调用陷阱，最终达成代码更易测试、复用、维护与调试的高质量架构目标。

控制器不该是业务逻辑的终点，而应是请求入口的守门人。精简的关键不是删代码，而是把不该在那儿的东西挪走——验证、领域规则、数据组装、第三方调用，全都不该卡在 UserController 的 store() 方法里。

FormRequest 封装验证逻辑，别在控制器里写 $request->validate()

硬编码验证规则会让控制器方法膨胀，且无法复用。Laravel 的 FormRequest 是专为此设计的解耦机制。

• 运行 php artisan make:request StoreUserRequest 生成独立验证类
• 在 rules() 中定义字段规则，在 authorize() 控制访问权限
• 控制器方法直接接收该 FormRequest 实例：public function store(StoreUserRequest $request) —— Laravel 自动拦截非法请求并返回 422，无需手动 if ($validator->fails())
• 同一个 StoreUserRequest 可被 update() 复用（只需覆盖 rules() 中的个别字段）

业务逻辑必须抽到 Service 类，控制器只负责“转手”

当控制器里出现 DB::transaction、Mail::send、$user->assignRole() 或多个模型联动操作时，说明它已经越界了。

• 新建 app/Services/UserRegistrationService.php，把用户创建 + 角色分配 + 欢迎邮件发送打包成一个方法 register(array $data)
• 控制器中通过构造函数注入：public function __construct(private UserRegistrationService $service)
• 方法体只剩三行：$user = $this->service->register($request->validated());、return response()->json($user, 201);
• 好处：单元测试可直接调用 $service->register()，不依赖 HTTP 层；队列任务、API 和后台命令也能复用同一套逻辑

避免控制器方法互相调用，尤其是带 Request 参数的

常见错误：在 someOtherMethod() 里写 $this->store($array)，结果报错 ArgumentCountError: Too few arguments —— 因为 store() 明确要求 Request 类型参数。

• 根本解法：把实际干活的逻辑从 store(Request $request) 中剥离出来，变成不依赖请求对象的纯方法，例如 createUser(array $data)
• 原控制器方法变成壳：public function store(StoreUserRequest $request) { return $this->createUser($request->validated()); }
• 其他内部方法就能安全调用 $this->createUser($array)，无需伪造 Request 实例
• 注意：别把 createUser() 做成 public —— 它不是 HTTP 入口，只是服务层的延伸，应设为 protected 或直接移到 Service 类里

最容易被忽略的是：控制器里混入任何非 HTTP 协议相关的逻辑，都会让测试变重、复用变难、调试变慢。哪怕只是一行 Storage::put() 或一次 Http::post()，都该出现在 Service 或 Action 类里，而不是控制器中。

终于介绍完啦！小伙伴们，这篇关于《Laravel控制器设计指南：单一职责实践》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！