选 apiResource 还是 resource，关键看控制器是否需响应 HTML 页面：只返回 JSON 用 apiResource，需渲染 Blade 视图则必须用 resource；因 apiResource 不注册 create/edit 路由，而 resource 注册全部 7 条（含表单页），且二者中间件、命名、模型绑定机制均不同。
选 apiResource 还是 resource，关键看你的控制器是否需要响应 HTML 页面 —— 如果只返回 JSON（比如前后端分离项目），用 apiResource；如果还要渲染 Blade 视图（比如带表单的管理后台），就得用 resource。
什么时候必须用 resource
当你控制器里有 create 或 edit 方法，并且它们会返回一个 HTML 表单页面时，resource 是唯一选择。因为 apiResource 根本不注册这两个路由。
-
resource('posts', PostController::class)会生成 7 条路由，包括GET /posts/create和GET /posts/{post}/edit -
apiResource('posts', PostController::class)只生成 5 条：仅index、show、store、update、destroy - 如果你硬在
apiResource下写了create方法但没配路由，访问/posts/create就直接 404
为什么 apiResource 默认不带 create 和 edit
因为 RESTful API 不该暴露“页面跳转逻辑”。前端自己决定要不要弹窗、跳路由、还是复用组件 —— 后端只管数据增删改查。所以 Laravel 把这两个“视图导向”的动作从 API 路由中剥离了。
-
create对应的是「获取空表单结构」，API 场景下通常由前端静态定义或通过GET /posts/fields等自定义端点提供 -
edit同理，前端直接GET /posts/{id}拿数据填充即可，无需单独路由 - 强行加
->only(['index','show','store','update','destroy','create'])会报错：create 不在apiResource的白名单里
混用或补路由的常见错误
有人想“保留 API 路由，但偶尔加个 create”，于是手动补一条：Route::get('posts/create', [PostController::class, 'create'])。这看似可行，但埋了三个坑：
- 路由名冲突：
posts.create已被resource占用，而apiResource不生成它 —— 但你手动加的这条路由不会自动获得标准命名，容易导致route()辅助函数失效 - 中间件不一致：比如你全局给
api中间件组加了throttle:api，但手动加的GET /posts/create走的是 web 组，漏掉限流 - 参数绑定失效：手动写的
{post}不会自动解析为模型实例，得自己写Post::findOrFail($id)，失去 Laravel 的隐式绑定便利
真正灵活的做法：按场景分组，别硬塞
一个控制器既服务 API 又服务后台页面？不是不行，但路由定义要分开。
- API 部分走
Route::prefix('api')->middleware('api')->group(...)，里面用apiResource - 后台页面部分走
Route::middleware('web')->group(...)，里面用resource - 控制器方法可以共用，但不要指望一套路由规则覆盖两种语义 —— create 的语义在 API 里不存在，在页面里才成立
最易被忽略的一点：资源路由的命名和参数绑定行为，完全由注册方式决定，跟控制器里有没有那个方法无关。写了个 create 方法，不代表路由就存在；删了 create 方法，只要路由还注册着，请求进来照样进到不存在的方法报 500。
