referrerpolicy属性是唯一能在HTML元素级精确控制Referer头内容的原生方式，但仅对<a>、<img>、<iframe>、<script>、<link>、<form>等主动发起网络请求的标签生效，不支持<div>、<p>等静态标签，且不能替代响应头或rel="noreferrer"的安全强度。
直接说结论：referrerpolicy 属性是唯一能在 HTML 元素级精确控制 Referer 头内容的原生方式，但它只对带网络请求行为的标签生效，且不能替代响应头或 rel="noreferrer" 的安全强度。
哪些 HTML 标签能用 referrerpolicy？
必须加在会主动发起网络请求的元素上，不是所有标签都支持。常见有效标签包括：<a>、<img>、<iframe>、<script>、<link>、<form>。其他如 <div>、<p> 或纯文本链接加了也无效。
容易踩的坑：
-
<a>加了referrerpolicy，但用户右键“在新标签页打开”，该属性被忽略，走浏览器默认策略 -
<iframe>的referrerpolicy控制的是 iframe 内部资源（比如它里面的<img>）向外发请求时的 Referer，不是父页面向 iframe 发请求时的 Referer -
<form>不显式写referrerpolicy就不会继承页面级<meta name="referrer">，必须手动加
referrerpolicy 值怎么选才不泄露敏感路径？
核心原则：跨源跳转时，避免暴露路径和查询参数（如 ?token=abc、/admin/user/123）。常用值行为差异明显：
立即学习“前端免费学习笔记（深入）”；
-
strict-origin-when-cross-origin：同源发完整 URL；跨源只发https://a.com；HTTPS→HTTP 时不发——推荐作为多数外链默认值 -
no-referrer：彻底不发 Referer 头——适合跳转到支付网关、第三方登录页等合规出口 -
origin：一律只发源——简单但粗暴，站内导航也会丢路径，影响分析归因 -
unsafe-url：强制发完整 URL（含路径和参数）——生产环境禁用，有严重隐私风险
注意：same-origin 和 strict-origin 在 referrerpolicy 属性中可用，但在 <meta name="referrer"> 中不支持，别混用。
和 rel="noreferrer"、响应头冲突时谁生效？
优先级从高到低：HTTP 响应头 > 元素级 referrerpolicy > <meta name="referrer">。但有个例外：no-referrer 在元素上设置时，会覆盖响应头（其他值不会）。
rel="noreferrer" 和 referrerpolicy="no-referrer" 不是等价替换：
-
rel="noreferrer"只作用于<a>和<area>点击跳转，彻底不发 Referer，且自动启用noopener防劫持 -
referrerpolicy="no-referrer"能用于更多标签（如<img>、<iframe>），但不带noopener，安全性弱一层 - 二者不能混用在同一标签上——浏览器会忽略
referrerpolicy，只认rel="noreferrer"
真正容易被忽略的点：JS 发起的 fetch() 或 XMLHttpRequest 完全不受 referrerpolicy 影响，必须靠服务端响应头统一控制；而用户右键新开标签的行为，HTML 层面几乎无法干预，只能靠响应头兜底。
