资源控制器仅适用于标准restful资源场景，如文章、用户等crud闭环管理；硬套于登录、支付等非资源操作会破坏约定、增加复杂度；api场景宜用apiresource，避免视图相关方法；遇多表联动、工作流删除、多步创建等高度定制化需求时应改用普通控制器。
资源控制器不是万能的，它只在明确符合 RESTful 资源语义、操作粒度标准、且不频繁突破 CRUD 边界的场景下才真正省力。用错地方反而会绕弯子、藏 bug、难调试。
适合标准 Web 表单管理后台
比如文章管理、用户列表、商品分类这类「列表 → 创建表单 → 提交保存 → 查看详情 → 编辑表单 → 更新 → 删除」完整闭环的页面流。Laravel 自动生成的 index、create、store、show、edit、update、destroy 七个方法刚好对齐，视图命名（articles.index、articles.create）和路由路径（/articles、/articles/create）也天然一致。
常见错误现象：硬套资源控制器去处理「登录」「支付回调」「导出 Excel」这类非资源动作，结果要在控制器里塞一堆 if 判断请求来源，或在路由里额外加 Route::post('articles/export', [...])，反而破坏约定。
- 必须确保模型存在且已配置好 Eloquent 关系（如
Article::with('author')） - 视图文件路径需严格匹配复数资源名，例如
resources/views/articles/index.blade.php - 如果后台用了权限中间件，建议统一在路由组中加
middleware(['auth', 'can:manage-articles'])，而不是分散写在每个方法里
适合 API 接口快速搭建（用 apiResource）
当你要暴露一个纯数据接口（如移动端或前端 SPA 调用），且不需要 HTML 渲染、不涉及 session 或 CSRF，直接用 Route::apiResource('posts', PostController::class) 更干净。它默认去掉 create 和 edit 这两个返回视图的方法，只保留 index、store、show、update、destroy，更贴合 API 语义。
性能影响：相比手动定义五条路由，apiResource 不增加运行时开销，但会略微增大路由缓存体积（可忽略）；兼容性上，Laravel 5.6+ 全支持，无需额外 polyfill。
-
apiResource默认禁用_method伪造（如 POST + _method=PUT），只认原生 HTTP 方法 - 若需批量操作（如
POST /posts/batch-delete），不能塞进资源控制器，得单独定义路由并指向新方法 - 返回 JSON 时，别在
store里用redirect()，应统一返回response()->json(...)或new PostResource($post)
不适合高度定制化或复合操作
一旦出现以下任一情况，就该停手、新建普通控制器或单独加路由：
- 一个「编辑」页面要同时加载 5 张关联表数据，且每张表更新逻辑完全不同（比如用户编辑页含 profile、settings、preferences 三张独立表）
- 「删除」不是软删也不是硬删，而是触发工作流（如审核中不可删、已发布需归档并通知运营）
- 「创建」需要多步引导（step 1→2→3）、跨表校验、异步上传后回填字段
- URL 要求带业务标识而非 ID，比如
/orders/ORD-2024-7890，而你又不想改全局路由参数绑定逻辑
容易踩的坑：试图用 only 或 except 去“裁剪”资源控制器来凑合用，结果留下空方法、冗余路由、隐藏的 404，后期接手的人根本看不出哪些是真实入口。
最常被忽略的一点：资源控制器默认不处理软删除模型的 trashed() 状态。如果你用 SoftDeletes，show 和 edit 方法拿到的 $id 可能查不到记录，得自己加 withTrashed() 或显式判断，这不是资源控制器的设计范畴。
