应选no-referrer的场景是跳转至支付网关、第三方登录页或GDPR要求零来源泄露的合规出口页，此时Referer头被彻底移除；而origin-when-cross-origin跨源仅发origin、同源仍发完整URL，适合兼顾内部跳转与外部引流，但存在被间接识别的风险。
referrerPolicy 是唯一能在 HTML 层级直接、可靠控制 Referer 头行为的原生机制，不依赖 JS，不触发重定向，且兼容所有现代浏览器（Chrome 64+、Firefox 69+、Safari 11.1+、Edge 79+）。它不能伪造 Referer，但能清空、截断或保留来源 URL 的不同粒度。
什么时候该用 no-referrer 而不是 origin-when-cross-origin
选 no-referrer 的核心场景是：你明确不希望下游页面知道任何上游信息——比如跳转到支付网关、第三方登录页、或 GDPR 要求“零来源泄露”的合规出口页。它会彻底移除 Referer 头，HTTP 请求里连 Origin 都不会带。
而 origin-when-cross-origin 只在跨源时发 origin（如 https://a.com），同源仍发完整 URL。它适合大多数内部跳转+外部引流兼顾的场景，但若下游是广告平台或分析服务，它们可能靠 origin 推断出你站点结构，仍存在间接识别风险。
常见错误现象：
立即学习“前端免费学习笔记（深入）”；
- 在跳转到 Stripe Checkout 页时用了
origin-when-cross-origin，结果 Stripe 日志里出现你域名的完整 path，被审计认定为“未最小化来源暴露” - 把
no-referrer误用于站内导航（如从 /blog 到 /about），导致 Analytics 丢失来源归因，误判为“直接流量”
strict-origin-when-cross-origin 是当前最平衡的默认值
这是 Chrome 85+、Firefox 90+、Safari 14+ 的浏览器默认策略，也是你在没写 referrerpolicy 时实际生效的行为。它按三档处理：
- 同源：发送完整 URL（/blog/post?id=123）
- 跨源 HTTPS → HTTPS：只发 origin（https://a.com）
- 跨源 HTTPS → HTTP：不发 Referer（防明文泄露）
它兼顾了分析可用性（同源路径保留）、安全（HTTPS→HTTP 不泄密）和隐私（跨源不露 path）。如果你没特殊理由，就别覆盖它——硬设成 no-referrer 反而让 GA4 或 Matomo 丢失关键归因维度。
性能影响几乎为零：它是纯声明式属性，不阻塞渲染，不触发额外请求。
HTML 中设置位置和优先级规则
referrerPolicy 可作用于三个层级，优先级从高到低：
-
<a href="..." referrerpolicy="no-referrer">—— 单个链接，最高优先级 -
<area>、<iframe>、<img>、<link>、<>script>等支持该属性的标签 -
<meta name="referrer" content="origin-when-cross-origin">—— 全局兜底，仅对 a/link/img/iframe 生效，对 fetch/XHR 无效
容易踩的坑：
- 在
<meta>里写content="no-referrer"，以为能管住所有请求，结果 JS 里的fetch()依然按浏览器默认策略发 Referer - 给
<iframe src="https://thirdparty.com">设referrerpolicy="no-referrer"，但 iframe 内部 JS 仍可通过document.referrer读到父页 URL（该属性只控 HTTP 头，不改 JS API） - 混用
<meta>和标签级属性，后者会覆盖前者，但调试时容易漏看哪个生效
和服务端 Referer 检查逻辑配合的关键点
前端设 referrerpolicy 只影响「发出」的 Referer，不影响服务端「接收」时的校验逻辑。如果你后端有类似 if (req.headers.referer.includes('trusted.com')) 的白名单判断，必须同步更新：
- 若前端用了
no-referrer，服务端不能再依赖 Referer 做权限判断——得换 token 或签名 - 若前端用了
origin-when-cross-origin，服务端正则要从匹配完整 URL 改为匹配 origin，否则https://a.com/blog和https://a.com/about都会失败 - 服务端永远不能假设 Referer 存在或可信：它可被客户端任意禁用、篡改或清空，只能作为辅助信号，不能替代 auth header 或 session 校验
真正容易被忽略的是：Referer 控制只是单向链路的一环。你清掉了发出的头，但若目标站自己记录了跳转来源（比如通过 URL 参数 ?ref=a.com），那隐私保护就前功尽弃——referrerpolicy 管不了这个。
