浏览器默认不发referer是因隐私安全限制：跨域且无rel="noopener/noreferrer"时自动清空；解决方法是使用rel="opener"，它既保留referer又允许window.opener访问。
target="_blank" 为什么默认不发 Referer？
浏览器出于隐私和安全考虑，对 target="_blank" 的链接做了限制：当同时满足两个条件时（rel="noopener" 或 rel="noreferrer" 缺失，且目标页与当前页不同源），Chrome、Firefox 等现代浏览器会主动清空 Referer 头。这不是 bug，而是规范行为——尤其在跨域场景下，Referer 可能泄露敏感路径或参数。
如何让 target="_blank" 保留 Referer？
核心是显式控制 rel 属性，避免触发浏览器的默认剥离逻辑：
- 去掉
rel="noopener"或rel="noreferrer"—— 这是最直接的方式，但会带来安全风险（新页面可通过window.opener访问原页面） - 改用
rel="opener"：它允许window.opener存在，同时明确保留Referer（Chrome 88+、Firefox 79+ 支持） - 如果必须兼顾安全与 Referer，可组合使用：
rel="opener noreferrer"不行，但rel="opener"单独用即可
示例写法：
<a href="https://example.com" target="_blank" rel="opener">跳转</a>
服务端能否绕过这个限制？
不能。Referer 是由浏览器在发起 HTTP 请求时自动添加的请求头，前端无法通过 JS 直接设置（fetch 的 referrer 选项仅限同源，且不适用于 <a></a> 自然跳转）。服务端永远收不到被浏览器策略拦截掉的 Referer —— 即使你用 meta referrer 全局声明，也无法覆盖 target="_blank" 的独立策略。
-
<meta name="referrer" content="always">对普通链接有效，但对target="_blank"无效 - 想稳定传递上下文，建议改用 URL 参数（如
?ref=dashboard）或 sessionStorage + 新页面主动读取
为什么有时 Referer 又出现了？
常见于以下情况，容易误判为“有时生效”：
- 同源跳转（比如从
https://a.com/page1到https://a.com/page2）：浏览器默认发送 Referer，不受target="_blank"影响 - 用户禁用了隐私模式或修改了浏览器策略（如 Chrome 启动参数加
--unsafely-treat-insecure-origin-as-secure） - 旧版浏览器（如 IE11）未实现该限制，但已无实际兼容价值
真正跨域 + target="_blank" 场景下，Referer 的缺失是确定性行为，别依赖它做关键逻辑判断。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
