控制器应仅作请求入口守门人，验证交由formrequest，业务逻辑抽至service类，避免混入非http逻辑。
控制器不该是业务逻辑的终点，而应是请求入口的守门人。精简的关键不是删代码，而是把不该在那儿的东西挪走——验证、领域规则、数据组装、第三方调用，全都不该卡在 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 类里，而不是控制器中。
