回退路由必须置于所有路由末尾，仅响应404而非405错误，不执行中间件且需独立配置于web.php和api.php中，避免依赖未定义命名路由。
回退路由必须放在所有路由定义的最底部，否则会被前面的路由规则拦截，根本不会触发。
Route::fallback() 必须写在 routes/web.php 或 routes/api.php 末尾
它不是“兜底逻辑”，而是 Laravel 路由匹配失败后的最后 fallback——前提是前面没其他路由能匹配上。一旦你把 Route::fallback() 写在 Route::get('/{any}', ...) 或带通配符的路由前面，它就永远执行不到。
- 错误写法：
Route::fallback(...); Route::get('/{slug}', ...);→fallback永远不执行 - 正确顺序：所有
get/post/resource等明确路由写完，最后一行才是Route::fallback() - 如果用了
Route::any('/', ...)或Route::match(['GET', 'POST'], '/{any?}', ...)，它们会吃掉几乎所有请求，fallback形同虚设
回退路由不能捕获 MethodNotAllowed（405）错误
Route::fallback() 只响应 NotFoundHttpException（404），对 POST 到一个只定义了 GET 的路径这类情况完全无感。比如访问 POST /missing-route，Laravel 抛的是 MethodNotAllowedHttpException，直接进异常处理器，不走 fallback。
- 要统一处理 405，得改
app/Exceptions/Handler.php的render()方法 - 常见判断方式：
if ($exception instanceof MethodNotAllowedHttpException) - 返回 JSON 还是视图，取决于你的 API 或 Web 场景，不能指望
fallback一并接管
回退路由里别直接写 redirect()->route() 而不校验命名路由是否存在
用 redirect()->route('not-found') 很常见，但如果 not-found 这个命名路由本身没定义，就会抛出 RouteNotFoundException，导致二次报错，用户看到白屏或 500。
- 安全做法：先用
Route::has('not-found')判断，再重定向 - 更稳妥：直接返回视图或 JSON，避免依赖另一条路由的可用性
- 示例：
Route::fallback(function () { return view('errors.404'); });—— 不引入额外路由依赖
API 路由和 Web 路由的 fallback 是独立的
routes/web.php 里的 fallback 不会影响 routes/api.php，反之亦然。因为它们被注册在不同路由组里（web 中间件组 vs api 中间件组），底层是两套匹配流程。
- 如果你希望 API 请求也走统一 404 响应，必须在
routes/api.php底部单独加一条Route::fallback() - 注意中间件差异：Web 的 fallback 默认有 session/csrf，API 的则没有，返回 JSON 更合理
- 别试图在
web.php里定义/api/*的 fallback —— 路由前缀和分组机制会阻止它生效
真正容易被忽略的是：fallback 不是“错误页面中间件”，它不参与中间件栈执行；一旦触发，中间件（比如 auth、throttle）已经跑完了，但 response 是全新构造的。所以你在 fallback 闭包里拿不到当前请求的认证用户对象，也不能复用某些请求级服务实例——得靠 request() 或 app() 显式取。
