redirect()->back()不可靠，因其依赖可能为空、被篡改或丢失的http referer头，易导致跳转失败、重复提交或报错；应优先使用redirect()->intended()或手动存取session url，并务必为fallback()指定已定义的命名路由。
redirect()->back() 不可靠，别无脑用。它依赖 HTTP Referer 头，而这个头可能为空、被篡改、来自外部域名，甚至在 POST 后触发重复提交。
为什么 redirect()->back() 经常跳错或报错
Referer 是浏览器发来的请求头字段，不是服务端维护的状态。以下情况会让 redirect()->back() 失效：
- 用户从书签或命令行 curl 访问页面（无 Referer）
- 上一页是 HTTPS，当前页是 HTTP（现代浏览器会丢弃 Referer）
- 用户从邮箱链接、微信内嵌浏览器、某些安卓 WebView 进入（Referer 被清空或不可信）
- POST 提交后立刻调用
back()，刷新页面时可能重复提交表单
此时 Laravel 默认 fallback 是 /（首页），但有时会抛出 InvalidArgumentException: Route [home] not defined 错误——因为 fallback 路由根本不存在。
redirect()->back()->fallback() 怎么写才安全
显式指定兜底路由，避免 404 或白屏：
return redirect()->back()->with('message', '删除成功')->fallback(route('posts.index'));
注意两点：
-
fallback()参数必须是**已定义的命名路由**，不能是字符串路径（如'/posts'） - 如果项目没定义
posts.index路由，运行时会直接报错，而不是静默降级 - 多个重定向链式调用时，
fallback()必须在最后，且只生效一次
比 back() 更稳的替代方案：用 redirect()->intended()
适用于登录、权限拦截等场景——用户被重定向到登录页前，Laravel 已自动存好原目标地址（url.intended）：
return redirect()->intended('/dashboard')->with('success', '欢迎回来');
但它不适用于普通操作（如删除、编辑）后的返回，因为 intended 只在中间件 RedirectIfAuthenticated 中写入，且默认只记录 GET 请求来源。
若你真需要“操作后回原列表”，更推荐手动存 URL：
- 在列表页（如
posts.index）进详情前，把当前 URL 存进 session：$request->session()->put('previous_list_url', url()->current()); - 在删除逻辑末尾读取并跳转：
return redirect($request->session()->pull('previous_list_url', route('posts.index')));
带闪存数据时，back() 和 redirect()->back() 有区别吗
没有本质区别。两者都走同一底层逻辑，back() 是辅助函数，等价于 redirect()->back()。
但要注意链式调用顺序：
-
back()->withInput()->with('error', '失败')✅ 正确：先保留输入，再设消息 -
back()->with('error', '失败')->withInput()❌ 无效：withInput()必须在最前，否则 old() 函数拿不到值
另外，withInput() 只对当前请求的 input 有效；如果上一页是 POST，old() 仍能取到值，但 Referer 已不可靠——这正是双重风险叠加点。
真正难处理的不是语法，而是 Referer 的不可控性。哪怕加了 fallback，也要确认那个 fallback 路由在所有环境（本地、测试、生产）都存在且可访问。否则，线上用户点删除，就卡在空白页，连错误提示都没有。
