laravel的route::resource()默认生成7个rest方法：index、create、store、show、edit、update、destroy；实际应用需用only()/except()按场景筛选，配合表单请求类实现验证复用与权限控制。
资源控制器不是“自动帮你写完所有逻辑”的魔法，而是按约定组织 CRUD 路由和方法的模板——用错时机或硬套默认行为，反而让代码更难维护。
resource() 路由注册后，哪些方法会自动生成？
Laravel 的 Route::resource() 默认绑定 7 个标准方法，对应典型 REST 操作。但实际项目里你大概率不会全用上，比如 destroy 可能要加软删除确认，show 可能要关联预加载。
-
index→ GET /posts（列表） -
create→ GET /posts/create（新建表单） -
store→ POST /posts（提交保存） -
show→ GET /posts/{post}（详情） -
edit→ GET /posts/{post}/edit（编辑表单） -
update→ PUT/PATCH /posts/{post}（更新） -
destroy→ DELETE /posts/{post}（删除）
注意：PUT 和 PATCH 都会路由到 update 方法，但前端表单必须显式带 _method=PATCH 才能绕过浏览器只支持 GET/POST 的限制。
什么时候该用 only()/except() 控制方法生成？
常见错误是把所有资源都无脑 resource('users', UserController::class)，结果暴露了 create/edit 给 API 接口，或者让后台管理路由和前端页面共用一个控制器，职责混乱。
- API 场景：通常只要
index、show、store、update、destroy，去掉create和edit（前端不渲染表单）→ 用only(['index', 'show', 'store', 'update', 'destroy']) - 后台管理：可能需要完整 7 个，但
store和update要校验管理员权限 → 这时别删方法，而是在控制器里加中间件或手动检查auth()->user()->can('manage-users') - 如果只是临时禁用某个动作（比如禁止直接删除），别删
destroy路由，而是在方法里抛abort(403)或重定向，否则前端 JS 调用DELETE会 404，不好调试
Resource 控制器里 $request->validate() 怎么写才不踩坑？
新手常把验证规则全堆在 store 和 update 里，导致重复、难复用、无法统一响应格式。Laravel 支持表单请求类（FormRequest），但很多人不知道它和资源控制器怎么配合。
- 运行
php artisan make:request StorePostRequest，在rules()方法里写验证逻辑 - 控制器方法签名直接类型提示该类：
public function store(StorePostRequest $request)，Laravel 会自动验证并返回 422 响应 -
update方法要用不同规则？再建一个UpdatePostRequest，别试图在同一个请求类里靠$this->route('post')判断是否为更新——规则耦合会导致测试困难、IDE 提示失效 - 注意：表单请求类的
authorize()方法默认返回false，不改就会 403；要么返回true，要么在里面写权限判断逻辑
为什么有时候 route:list 看不到 resource 路由？
最常见原因是没跑 php artisan route:clear，尤其在修改了 routes/web.php 后还开着 php artisan serve，缓存没刷新。但还有几个更隐蔽的点：
- 路由定义在
routes/api.php却用php artisan route:list查，默认只查 web 组 → 加--except-vendor --path=api参数 - 用了
middleware(['web'])但当前路由组已套了web中间件组，导致重复包裹，某些 Laravel 版本会静默跳过 → 检查app/Providers/RouteServiceProvider.php的mapWebRoutes()是否重复注册 - 控制器类名拼错，比如写了
UserContrller少个o，Laravel 不报错，只跳过该路由 → 用php artisan route:list --name=users.index精确查，看有没有 “Action” 列为空
真正麻烦的是嵌套路由（比如 admin/posts）+ 资源控制器组合时，命名前缀、参数绑定、中间件作用域容易错层。这种场景建议先用普通路由写一遍，跑通再抽象成 resource —— 约定省力，但前提是团队对约定有共识，而不是靠文档猜。
