ThinkPHP 的 server() 方法仅用于读取 $_SERVER 变量，不可设置响应头；header() 是 PHP 原生函数，用于发送响应头，但需在任何输出前调用且易与框架机制冲突；正确做法是使用 redirect() 或 json() 等框架封装的响应方法。
ThinkPHP 的 server() 方法是获取服务器变量，不是设置响应头
很多人看到 server() 就下意识以为它和 header() 一样能控制 HTTP 响应，其实完全不是一回事。server() 是对 $_SERVER 超全局数组的封装，只读、只取、不发任何头信息。它返回的是当前请求的环境上下文，比如客户端 IP、请求方法、Host、User-Agent 等。
常见误用场景包括：想用 $this->request->server('HTTP_REFERER') 来“设置”来源页跳转，或试图靠它触发重定向——这根本不可能生效。
-
server()返回值是字符串或数组，例如server('REQUEST_METHOD')得到"GET"，server('HTTP_HOST')得到"example.com" - 它不接受任何写入参数，调用
server('X-Forwarded-For', '1.2.3.4')会报错或静默忽略 - 在中间件或控制器中频繁调用不会影响响应，但滥用（如反复取相同键）可能轻微拖慢性能
header() 是原生 PHP 函数，ThinkPHP 中直接可用但需谨慎
ThinkPHP 并没有封装一个叫 header() 的方法，你写的 header("Location: /login") 就是 PHP 原生函数。它直接向 SAPI（如 Apache/FPM）输出 HTTP 头，一旦发送成功，就无法撤回。
在 ThinkPHP 里调用它，风险比裸 PHP 更高，因为框架内部可能已提前输出内容（比如 Trace 日志、调试栏、异常堆栈），导致 headers already sent 报错。
立即学习“PHP免费学习笔记（深入）”；
- 必须在任何
echo、var_dump、模板输出、json()之前调用 - 跳转后务必接
exit或die，否则后续代码仍会执行（比如删库逻辑还在跑） - ThinkPHP 6 默认开启调试模式时，
header()极易失败；生产环境关闭调试后才相对稳定 - 不推荐在控制器中混用
header()和框架响应方法（如redirect()、json()），容易冲突
真正该用的 ThinkPHP 响应方法是 redirect() 和 json()
ThinkPHP 提供了语义明确、安全可控的响应方式：redirect() 封装了 header("Location: ...") 并自动 exit；json() 封装了 header("Content-Type: application/json; charset=utf-8") 加 json_encode()，还处理了中文转义和错误响应。
它们和原生 header() 的关键区别在于：是否纳入框架响应生命周期管理。绕过它，等于放弃中间件、钩子、日志记录等整套机制。
-
redirect('user/profile')→ 自动拼 URL、设 302、终止流程，比手写header()安全得多 -
return json(['code' => 0, 'data' => $list])→ 自动设头、编码、返回 Response 对象，且支持链式配置如json(...)->withCookie(...) - 如果硬要用原生
header()，请先确认没开启调试模式、没加载 Trace 插件、没调过dump()或trace()
为什么有人混淆 server() 和 header()？
因为命名太像，又都带 “server” 和 “header” 字眼，加上文档里常把 Request::header()（获取请求头）和 header()（发送响应头）并列说明，新手极易看串行。
更隐蔽的问题是：Request::header() 是读请求头（如 Authorization），header() 是写响应头（如 Location），二者方向相反、作用对象不同、调用时机也不同——前者在请求解析阶段，后者在响应生成末尾。
-
$this->request->header('authorization')→ 拿客户端发来的 token -
header('X-Frame-Options: DENY')→ 告诉浏览器别让本站被 iframe 套嵌 - 混用这两者，轻则逻辑错乱，重则安全策略失效（比如本该设
SecureCookie 却去读了个空 header）
