HTTP_REFERER不可直接信任，因其可被禁用、丢失或伪造，需校验空值及域名白名单；更安全的方式是前端显式传参（如?from=）并严格过滤校验。
直接用 $request->server('HTTP_REFERER')，但必须加空值和来源可信性校验，否则不可靠。
为什么 HTTP_REFERER 不能直接信
浏览器不强制发送该头，用户禁用、HTTPS→HTTP跳转、某些客户端（如微信内嵌浏览器、APP WebView）可能完全不带；更严重的是，它可被任意伪造——curl -H "Referer: https://evil.com" ... 就能绕过所有基于它的判断。
- 线上环境常见现象：日志里大量出现
https://www.google.com或空字符串，实际调用却来自小程序或内部系统 - 若业务依赖 Referer 做权限跳转（如登录后回跳），未校验就直接
redirect($referer)，会引发开放重定向漏洞 -
$request->header('referer')和$request->server('HTTP_REFERER')效果一致，但前者更统一；注意大小写不敏感，ThinkPHP 内部已做标准化
怎么安全地提取并使用上一页 URL
只在明确需要“用户从哪来”时才读取，且必须走白名单机制。不要用于身份识别或权限控制。
- 先判空：
if (!$referer = $request->server('HTTP_REFERER')) { return '/'; } - 再解析域名：
$parsed = parse_url($referer); $host = $parsed['host'] ?? ''; - 比对可信域名（硬编码或配置）：
in_array($host, ['example.com', 'admin.example.com', 'app.example.net']) - 拒绝含特殊字符、端口非标准（如 :8080）、路径含
javascript:或data:的 Referer - 最终跳转前，用
url()->build()或Url::build()重新生成目标地址，避免原始字符串直出
替代方案：用显式参数传递来源
Referer 不可靠时，更推荐前端主动传来源标识，比如登录页链接写成 /login?from=/order/create，后端用 $request->get('from') 取值。
立即学习“PHP免费学习笔记（深入）”；
- 优势：完全可控、无伪造风险、兼容所有客户端（包括 CLI 调用或定时任务触发的跳转）
- 注意过滤：
$from = $request->get('from', '', 'htmlspecialchars');防 XSS，再用Url::build($from)校验是否为站内路径 - 若需保留原始 Query，别用
parse_url($from, PHP_URL_PATH)简单截取——应走路由解析器判断是否匹配当前应用的合法路由规则 - 对 API 接口，Referer 几乎无意义，应改用
X-Referer-ID这类自定义头 + 签名验证
Referer 是个“尽力而为”的线索，不是事实。真正关键的来源信息（比如谁调用了这个接口、从哪个系统来的）得靠 X-App-ID、API Key 或 JWT claim 来承载，而不是指望浏览器随便填的一个 header。
