referrer 标签（更准确说是 <meta name="referrer">）的作用是告诉浏览器：在发起后续所有 HTTP 请求（比如图片、脚本、iframe、fetch、XMLHttpRequest）时，如何处理 Referer 请求头的值。
为什么需要控制 Referer 头？
默认情况下，浏览器会在跳转或资源请求中自动带上来源 URL 的 Referer 头。但这个行为有两方面风险：
- 泄露敏感路径（比如
https://site.com/admin?token=abc跳到第三方 CDN，Referer可能暴露 token） - 跨域请求时，某些目标站会因
Referer不合法直接拒绝（如要求必须为同源或为空）
用 <meta name="referrer" content="..."> 可以统一干预整页行为，比逐个加 referrerpolicy 属性更省事（尤其对内嵌资源）。
content 值有哪些？分别什么效果？
它只接受几个固定字符串，不是自由填写的策略名：
-
no-referrer：所有请求都不带Referer头（最严格，适合高敏页面） -
no-referrer-when-downgrade（浏览器默认值）：HTTPS → HTTP 时去掉，其余保留 -
origin：只发源（https://a.com），不带路径和查询参数 -
origin-when-cross-origin：同源请求发完整 URL，跨域只发源 -
unsafe-url：始终发完整 URL（不推荐，有泄漏风险）
注意：strict-origin 和 strict-origin-when-cross-origin 也存在，但 IE 完全不支持，且 Safari 对前者兼容性差，线上慎用。
和 referrerpolicy 属性冲突怎么办？
两者作用范围不同，但有优先级：
-
<meta>全局生效，影响页面内所有自动发起的请求（<img>、<script>、<iframe>、CSS @import 等） -
referrerpolicy属性只作用于单个元素（如<img referrerpolicy="no-referrer">） - 当两者同时存在，元素级属性优先级更高 —— 也就是说，
<meta>是兜底策略，个别资源可覆盖
常见错误：在页面写了 <meta name="referrer" content="origin">，又给某个埋点 <img> 加了 referrerpolicy="no-referrer"，结果发现埋点没发 Referer —— 这不是 bug，是预期行为。
容易被忽略的兼容性和陷阱
这个 <meta> 标签必须放在 <head> 里，且越靠前越好；如果 JS 动态插入，多数浏览器会忽略。
- Chrome / Firefox / Edge 支持良好，但 Safari 15.4 之前对
strict-*值支持不全 - 它**不控制**
fetch()或XMLHttpRequest的Referer行为 —— 这些由请求发起时的referrerPolicy选项决定 - 服务端不能依赖它做权限判断，因为它是客户端声明，可被绕过（比如 curl 直接请求）
- 如果用了 CSP，
reflected-xss或base-uri等指令不会影响referrer行为，别混为一谈
真正要管住 Referer，得看三处：meta 标签（全局静态资源）、元素属性（单点覆盖）、JS 请求选项（动态逻辑）。少盯漏一个，就可能在监控日志里看到不该出现的路径。
