<meta name="referrer">不是精细化工具，因其仅作为全页兜底策略，只控制HTML自动发起的导航类请求（如链接跳转、表单提交、资源加载），对fetch()、XMLHttpRequest、<iframe>加载、JS跳转等完全无效，且不支持same-origin等部分策略值。
它不能精细化控制——meta name="referrer" 是粗粒度兜底策略，只对页面后续自动发起的导航类请求生效，且无法覆盖 JS 请求、<iframe> 加载、表单提交或跳转逻辑。
为什么 meta name="referrer" 不是“精细化”工具
这个标签的设计定位就是「全页默认值」，不是逐元素调节的开关。它只影响浏览器解析完该 <meta> 后，由 HTML 自动触发的请求，比如：<a href="https://other.com"> 点击跳转、<form action="..."> 提交（除非 <form> 显式写了 referrerpolicy）、<link rel="stylesheet">、<img>、CSS 中的 @import 等。
但它对以下行为完全无效：
-
fetch()和XMLHttpRequest—— 必须在调用时显式传referrerPolicy选项 -
window.location.href = "https://...";或location.replace() -
<iframe src="...">的加载（哪怕加了referrerpolicy属性也得单独设） - 用户右键“在新标签页打开”
meta name="referrer" 的 content 值怎么选才不踩坑
可用值是固定枚举，不是自由字符串；写错（如拼成 origin-when-crossorigin）会被浏览器忽略，退回到默认策略 no-referrer-when-downgrade。
立即学习“前端免费学习笔记（深入）”；
-
no-referrer：所有请求都不带Referer头 —— 适合支付结果页、含临时令牌的跳转出口页 -
origin-when-cross-origin：同源发完整 URL（含路径和参数），跨源只发https://a.com—— 推荐作为多数页面默认值，平衡分析可用性与路径隐藏 -
strict-origin-when-cross-origin：同源发完整 URL，跨源发 origin，且 HTTPS → HTTP 时不发 —— 更安全，但 Safari 15.4 之前兼容性差，线上慎用 -
origin：一律只发源 —— 简单粗暴，适合不想暴露任何路径的静态站点 -
unsafe-url：始终发完整 URL —— 有严重隐私风险，生产环境应避免
注意：meta 不支持 same-origin、strict-origin 等部分策略值，这些只在 HTTP 响应头或元素级 referrerpolicy 中有效。
和 referrerpolicy 属性冲突时谁赢
元素级属性优先级永远高于 meta。也就是说：meta 是兜底，referrerpolicy 是 override。
- 全局设了
<meta name="referrer" content="origin">，但某个埋点图加了<img src="log.gif" referrerpolicy="no-referrer">→ 这张图确实不发Referer - 反过来，如果只靠
meta控制，却给外链加了rel="noreferrer"→ 点击时不仅清掉Referer，还会清掉window.opener，比referrerpolicy="no-referrer"更彻底
真正要管住来源信息，必须同时考虑三处：Referrer-Policy 响应头（最高优先级）、meta name="referrer"（HTML 兜底）、元素级 referrerpolicy（单点覆盖）。
最容易被忽略的实操细节
meta name="referrer" 必须放在 <head> 内，且越靠前越好 —— 浏览器解析到即生效，后续动态插入（比如用 JS 执行 document.head.appendChild()）基本无效。
它只作用于当前 HTML 文档发起的请求，不会继承、不传递、不跨 iframe。验证时别只看 DevTools Network 面板里某次跳转的 Referer，要抓服务端原始日志，因为重定向、缓存、CDN 都可能干扰前端看到的内容。
如果你的页面大量依赖 fetch() 或嵌入第三方 <iframe>，meta 标签几乎起不到实际作用 —— 这时候必须转向响应头或元素级属性，否则策略就只是摆设。
