ThinkPHP 的 success 和 error 方法本质是渲染内置跳转模板并执行页面内 JS 跳转，不阻断 PHP 执行，禁用 JS 时失效；调用后必须 return，否则后续代码仍运行。
ThinkPHP 的 success 和 error 方法本质是模板渲染 + HTTP 跳转
它们不是单纯的 JS 重定向或 header 跳转，而是先渲染一个内置的跳转模板（dispatch_jump.tpl），再通过页面内 JS 执行 window.location.href。这意味着：跳转行为依赖前端 JS，禁用 JS 时会卡在空白提示页；同时它不阻断后续 PHP 执行——如果你在 success() 后写了数据库操作，那段代码仍会运行。
- 默认模板路径为
thinkphp/tpl/dispatch_jump.tpl，可被自定义模板覆盖（通过配置dispatch_success_tmpl或dispatch_error_tmpl） - 方法内部调用的是
redirect()的变体，但封装了状态码、提示语、延迟时间等参数，最终输出的是 HTML + 内联 JS - 返回值是
Response对象，所以可以链式调用如->header(...)->send()，但通常不需要
success 和 error 的参数差异与常见误用
两者签名一致：success($msg, $url = '', $data = [], $wait = 3)，但语义和默认跳转目标不同。最容易出问题的是 $url 参数为空时的行为：
-
success()默认跳转到$_SERVER['HTTP_REFERER']（上一页），若不可用则 fallback 到/ -
error()默认跳转到javascript:history.back(-1)，即浏览器后退——这在从 POST 提交后直接 error，再点后退可能重复提交 -
$data是传给模板的额外变量，比如['token' => $token]，但模板里必须手动使用，框架不自动注入到跳转 URL - 如果
$url是相对路径（如'user/index'），会被自动解析为 URL 路由地址；如果是完整 URL（含http://），则原样输出
禁用 JS 时跳转失败？你需要手动 fallback 或改用 redirect()
当用户禁用 JS，success/error 渲染的页面就停在“正在跳转…”上，没有任何响应。这不是 Bug，是设计使然。生产环境应避免依赖它做关键跳转。
- 简单 fallback：在模板中加
<meta http-equiv="refresh" content="3;url=xxx">，但需自定义模板并开启dispatch_*_tmpl配置 - 更稳妥的做法：对关键操作（如登录成功、支付回调）直接用
redirect($url)->send()，它走纯 header 跳转，不依赖 JS - 注意：
redirect()不带提示语，也不渲染模板，适合 API 场景或后台管理中的静默跳转 - 混合方案：先
success()给用户友好提示，再在模板里加一段navigator.onLine检测 + 手动触发跳转逻辑（小众，一般没必要）
为什么有时跳转后 session 丢失或数据没写入？
因为 success/error 不终止脚本执行，只是输出 HTML 并结束当前响应体。如果控制器方法没 return 或 exit，PHP 会继续往下跑——尤其是你忘了在 success() 后加 return。
立即学习“PHP免费学习笔记（深入）”；
- 典型错误写法：
success('ok', 'index/index'); // 缺少 return Db::name('log')->insert(['action'=>'submit']); // 这行仍会执行，但响应已发出，用户看不到结果 - 正确做法：所有
success/error调用后必须紧跟return，否则后续逻辑可能污染响应、引发 headers already sent 错误，或造成数据异常 - 另一个隐藏坑：如果跳转前启用了输出缓冲（ob_start），而模板渲染触发了 flush，可能导致 header 发送失败，进而让跳转 JS 失效——建议统一关闭 ob 或确保它不干扰响应流
真正要小心的从来不是怎么跳，而是跳完之后 PHP 还在不在跑。别信“方法名带 success 就万事大吉”。
