闭包路由仅适用于本地快速验证、临时调试或极简静态页；超过3条即应警觉，涉及表单、用户状态、重定向或未来API化时须立即改用控制器。
直接在 routes/web.php 里写 Route::get() 就能跑起来，但真要上线或协作开发，只靠闭包会很快失控——控制器绑定、参数约束、命名和分组不是可选项，是避免后期返工的硬性前提。
闭包路由适合什么场景？什么时候该停手？
闭包路由（function () { return 'xxx'; }）只适用于本地快速验证、临时调试或极简静态页。它没有测试友好性，无法复用逻辑，也不能被中间件统一拦截（比如权限判断），更没法加 PHPDoc 或单元测试。
- 能接受「改一处就要改路由文件+所有调用点」的，可以继续用
- 只要涉及表单提交、用户状态、跳转重定向、或未来可能拆成 API 的，立刻换控制器
-
Route::get('/test', function () { ... })在web.php里超过 3 条，就该警觉了
带参数的路由为什么总 404？关键看三点
常见错误不是写错语法，而是忽略 Laravel 的匹配优先级和约束生效时机：
- URL 中的
{id}是路径段，不包含查询参数（?page=2是另一回事） - 必须用
->where('id', '[0-9]+')显式约束，否则/user/abc仍会进路由，只是$id值为字符串'abc'，后续find()可能静默失败 - 多个参数路由如
/post/{category}/{id}，要确保它没被上面更宽泛的路由（比如/post/{slug}）提前匹配掉——Laravel 按定义顺序匹配，先定义的优先
资源路由生成的 7 个动作，哪些其实不该暴露？
Route::resource('posts', PostController::class) 默认注册全部 7 个动作，但真实项目里 create 和 edit 很少需要独立路由（它们通常由 index 或 show 页面内联表单处理），而 destroy 必须配中间件防 CSRF 或权限绕过。
- 用
->only(['index', 'show', 'store'])明确收口，比事后删控制器方法更安全 -
store和update动作默认走POST/PUT，但前端若用 fetch +method: 'put'，得确认是否已加载@csrf和@method('PUT') - 资源路由的命名是固定的，比如
posts.index，别试图用name('blog.posts.list')覆盖——它会失效
web.php 和 api.php 别混用，中间件差异是隐形炸弹
两个文件看似只是路径不同，但底层中间件栈完全不同：web.php 自动套 web 中间件组（含 session、CSRF、加密 cookie），api.php 用的是无状态 api 组（依赖 token、无 session）。
- 把本该给前端页面用的
/profile写进api.php，登录态会丢失，Auth::user()返回 null - 把 API 接口（如
/api/v1/users）误写进web.php，CSRF 验证会拦截所有 POST 请求，前端报 419 - 跨域请求（CORS）在
api.php中默认启用，在web.php中需手动加->middleware('cors')
最常被忽略的其实是路由缓存：开发时改完 web.php 立刻生效，但上线后若执行过 php artisan route:cache，再改路由文件也不会刷新——得重新缓存，或者干脆在部署流程里加这一步。
