referrerpolicy属性应加在发起请求的html标签上，如、、、、、等，局部设置优先级高于或响应头。
referrerpolicy 属性该加在哪个 HTML 标签上？
它必须加在发起请求的标签上，不是全局声明。常见可设位置有：<a></a>、<img>、<iframe></iframe>、<script></script>、<link>（如预加载）、<form></form>。每个标签独立生效，局部设置优先级高于页面级 <meta> 或响应头。
容易踩的坑：
-
<meta name="referrer" content="...">只影响后续导航（点击链接、表单提交），对fetch()、XMLHttpRequest、动态插入的<img>无效 - 给
<a></a>加了referrerpolicy，但用户右键“在新标签页打开”，仍走浏览器默认策略（除非同时加rel="noreferrer"） -
<iframe></iframe>的referrerpolicy控制的是 iframe 向外发请求时的 Referer，不是父页面向 iframe 发请求时的 Referer
strict-origin-when-cross-origin 和 no-referrer-when-downgrade 有什么实际区别？
关键在「协议降级」和「跨源」两个维度是否发送完整 URL。二者都是常用策略，但行为不同：
-
no-referrer-when-downgrade（默认）：HTTPS → HTTP 时不发 Referer；HTTPS → HTTPS 或 HTTP → HTTP 都发完整 URL -
strict-origin-when-cross-origin（推荐）：同源（如https://a.com/page1→https://a.com/page2）发完整 URL；跨源（如https://a.com→https://b.com）只发https://a.com；HTTPS → HTTP 时完全不发
举例：你从 https://shop.example.com/checkout?uid=123&token=abc 跳转到 https://payment.gateway/pay，用 strict-origin-when-cross-origin，对方收到的 Referer 是 https://shop.example.com；用默认值则可能是带敏感参数的完整 URL —— 这就是为什么不能依赖默认值做隐私保护。
后端配 Referrer-Policy 响应头 vs 前端加 referrerpolicy 属性，哪个更可靠？
二者不是二选一，而是分层补位：
- 响应头（如
Referrer-Policy: strict-origin-when-cross-origin）由后端统一配置，覆盖所有本域发起的请求（含 JSfetch()、XMLHttpRequest、资源加载），且不可被前端 JS 覆盖 -
referrerpolicy属性只作用于对应 HTML 元素，对脚本发起的请求无效；但它能控制用户主动点击的外链，这是响应头管不到的场景 - 最稳妥的做法是：后端配响应头 + 关键外链显式加
referrerpolicy="no-referrer"或rel="noreferrer"
注意：rel="noreferrer" 比 referrerpolicy="no-referrer" 更彻底——它不仅清 Referer，还隐式启用 noopener，防止新开页通过 window.opener 反向控制原页面，安全收益更高。
哪些 referrerpolicy 值绝对不要用？
unsafe-url 是唯一明确应禁用的值。它强制在所有情况下发送完整 URL（含路径、查询参数），哪怕是从 HTTPS 页面跳到 HTTP 页面，也会明文泄露敏感信息（如 ?session_id=xxx、&code=yyy）。
其他需谨慎的场景：
-
origin看似安全，但如果源本身包含敏感子域（如admin.internal.example.com），暴露源仍可能暴露架构信息 -
same-origin在单页应用中可能导致分析工具收不到内部路由跳转的 Referer，影响埋点准确性 - 空字符串或不设值，等于退回到浏览器默认策略（
no-referrer-when-downgrade），对隐私敏感场景不够用
真正难处理的是混合场景：比如一个页面既要向自家 CDN 加载图片（希望带 origin），又要跳转到第三方支付（必须清 Referer）。这时不能靠全局策略，只能逐个元素控制，且要配合 CSP 的 referrer 指令避免冲突。
