laravel常规web路由写在routes/web.php，api路由写在routes/api.php；二者由框架自动加载，误改routes/console.php或自建文件会导致路由不生效。
路由定义写在哪个文件里
Laravel 的常规 Web 路由统一写在 routes/web.php，API 路由则放在 routes/api.php。这两个文件由框架自动加载，不需要手动引入——但很多人改了路由不生效，其实是误改了 routes/console.php 或自建的 PHP 文件，那些不会被自动注册。
常见错误现象：Route [xxx] not defined 或访问 404，但 php artisan route:list 里完全看不到你写的路由——大概率是文件放错位置，或没加 Route:: 前缀（比如直接写了 get('/home', ...)）。
- Web 路由默认带 Session、CSRF、全局中间件，适合带页面的请求
- API 路由默认无 Session、无 CSRF，返回 JSON，适合前后端分离或移动端调用
- 别在
app/Providers/RouteServiceProvider.php里硬编码路由——那是用来配置路由加载逻辑的，不是写路由的地方
怎么写一个带参数的 GET 路由
用 Route::get() 定义，参数用花括号包裹，比如 {id} 或 {slug}。Laravel 默认把它们当作必需参数，且不做类型限制——/post/abc 和 /post/123 都能匹配 Route::get('/post/{id}', ...)。
容易踩的坑：没加约束时，{id} 可能被恶意传入 SQL 注入字符串或长路径，后端还得自己校验；加约束能提前拦截，也利于路由优先级判断（比如更具体的路由要写在前面）。
- 加正则约束：
->where('id', '[0-9]+')，这样/post/abc直接 404 - 可选参数写法：
{id?}，但必须配合默认值或在控制器里判空，否则调用$request->route('id')可能为 null - 多个参数顺序必须和 URL 路径严格一致，
/user/{id}/post/{post_id}不能颠倒
POST 表单提交总报 419 错误
这是 CSRF 验证失败，不是路由写错了。Laravel 默认对所有非 GET/HEAD/OPTIONS 请求强制验证 _token 字段，而新手常漏掉表单里的 @csrf Blade 指令或手动加 <input type="hidden" name="_token" value="{{ csrf_token() }}">。
使用场景：只要用 Route::post()、Route::put() 等非安全方法，且走的是 web 中间件组（即写在 web.php），就绕不开这个检查。
- API 路由（
api.php）默认不启用 CSRF，所以 POST 不会 419——但也不能直接拿它接 HTML 表单，因为没 Session - 临时关闭 CSRF（仅调试）：在
app/Http/Middleware/VerifyCsrfToken.php的$except数组里加路径，如'/debug/*' - 用 Postman 测试时，记得手动加 Header：
X-XSRF-TOKEN: xxx，值从XSRF-TOKENCookie 里取（需先 GET 一次页面）
路由命名和重定向时的坑
用 ->name('profile.show') 给路由起名，是为了后续用 route('profile.show', ['id' => 1]) 生成 URL。但名字重复、参数缺失或类型错位，都会让 route() 返回 null 或抛出异常。
性能影响不大，但命名混乱会导致后期维护成本陡增——尤其当团队多人协作、或项目接入了 Laravel Nova、Filament 这类依赖命名路由的工具时。
- 命名必须全局唯一，同名会覆盖，且
php artisan route:list里只显示最后一个 - 传参必须和路由定义的参数名完全一致，
route('user.show', ['user_id' => 1])对不上{id}就失效 - 重定向时慎用
redirect()->route(...)代替redirect('/xxx')：前者依赖路由存在且参数合法，后者只是硬跳转，更“钝”但更稳
最常被忽略的一点：路由缓存（php artisan route:cache）只缓存 routes/web.php 和 routes/api.php，如果你把路由分散写在其他文件里，缓存后它们就彻底失效了。
