success/error 不是底层重定向，而是渲染JS跳转模板，易因输出污染、缓存、路径错误等导致白屏或不跳转；推荐用 redirect() 实现服务端302跳转，更可靠可控。
ThinkPHP 的 success 和 error 不是必须用的跳转方式，也不是底层重定向机制；它们只是封装了模板渲染 + 前端 JS 跳转的组合逻辑，实际项目中容易因配置或前端环境导致跳转失败，建议优先用 redirect()。
为什么 success/error 经常不跳转或白屏
这两个方法本质是：渲染一个内置提示模板（如 thinkphp/tpl/dispatch_jump.tpl），里面靠一段 JS 执行 window.location.href 或 history.back()。所以问题几乎都出在前端环节：
- 页面已输出内容（比如提前
echo或开启调试时输出了 warning），导致 header 无法发送，JS 模板虽渲染但可能被截断 - 响应头被缓存（尤其是 Nginx 配置了
add_header Cache-Control "no-cache"缺失时），浏览器直接读缓存页，JS 不执行 - 模板路径被自定义覆盖但未提供对应 tpl 文件，报
Template not found错误却静默失败 - 使用 AJAX 提交后调用
success()，结果把跳转 JS 当作响应体返回给 JS 代码，前端没解析执行
redirect() 才是真重定向，且更可控
redirect() 是 ThinkPHP 5.1+ 的标准重定向方法，底层调用 header("Location: ...")，服务端直接发 302 响应，不依赖前端 JS：
- 支持相对路径：
$this->redirect('index/index') - 支持带参数：
$this->redirect('user/read', ['id' => 5, 'status' => 'ok']) - 支持外部 URL（需显式加协议）：
$this->redirect('https://example.com') - 可设 HTTP 状态码：
$this->redirect('admin/login', [], 301) - 调用后会自动
exit，无需手动终止流程
注意：如果已在控制器中调用了 echo、var_dump 或开启了输出缓冲但未 clean，redirect() 会抛出 headers already sent 错误 —— 这反而是个好信号，说明你该清理前置输出了。
立即学习“PHP免费学习笔记（深入）”；
想保留 success/error 的 UI 效果？自己封装跳转 + 提示
如果你喜欢 success() 那种带图标和延迟的提示效果，又不想受模板和 JS 限制，推荐用前后端分离思路：
- 后端统一返回 JSON：
return json(['code' => 1, 'msg' => '操作成功', 'url' => url('index/index')]); - 前端 JS 收到后，用
layer.msg()、Toast或ElMessage显示提示，再用window.location.href = res.url跳转 - 这样既规避了模板路径、缓存、输出污染等问题，又能灵活控制延时、动画、按钮行为
硬要复用 TP 原生逻辑？可以复制 thinkphp/library/think/Controller.php 中的 success() 方法，把模板渲染部分换成 json() 输出，再让前端接管跳转 —— 但不如直接换掉。
兼容旧版（TP5.0）要注意的坑
TP5.0 的 success() 默认跳转地址是 __FROM__（即来源页），这个值来自 $_SERVER['HTTP_REFERER']，极不可靠：
- 用户禁用 referer、从书签进入、HTTPS → HTTP 跳转都会丢失
- 没来源时默认跳首页，但有些部署环境下会跳成空地址或报错
- TP5.1+ 已改为默认跳
/，并允许传入$url参数覆盖
所以无论哪个版本，都别依赖默认跳转地址。显式传参才是唯一靠谱做法：$this->success('提交成功', 'article/index');
真正关键的不是选 success 还是 redirect，而是想清楚：这次跳转是否必须由服务端强控？是否允许前端感知失败并重试？是否要兼容无 JS 环境？—— 把这些理清了，方法自然就定了。
