控制器应仅作请求入口守门人，验证交由formrequest、业务逻辑移至service类、剥离纯方法避免耦合、资源控制器只保留标准crud——职责清晰才是精简本质。
控制器不该是业务逻辑的终点，而应是请求入口的守门人。精简的关键不是删代码，而是把不该在那儿的东西挪走——验证、领域规则、数据组装、第三方调用，全都不该卡在 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 类里
资源控制器和 Trait 能省事，但别滥用
php artisan make:controller UserController --resource 自动生成的 7 个方法看似省力，但容易掩盖职责混乱。比如 index() 里塞搜索、分页、导出逻辑，就违背单一职责。
- 资源方法只保留标准 CRUD 行为；复杂查询（如带多条件筛选的列表）另起专用方法，如
searchUsers() - Trait 可封装通用视图渲染（如
showList(Model::class, 'users.index', 'users')），但别往里面塞业务判断或数据库操作 - 如果多个控制器共用同一套增删改查逻辑，优先考虑 Service + Repository 模式，而非靠 Trait 硬拼凑
最常被忽略的一点：精简控制器不是为了代码行数变少，而是让「谁该对什么负责」一目了然。一旦你发现要给控制器方法加注释才能说明它在干什么，那大概率它已经装了太多东西。
