referrerpolicy是HTML中控制Referer请求头是否发送及发送内容的关键属性，必须显式设在标签上才能控制跨源跳转时的Referer行为；它仅对单次请求生效，优先级高于和响应头，值为no-referrer时彻底不发Referer，origin时只发协议+域名+端口，未设置则按浏览器默认策略no-referrer-when-downgrade处理。
referrerpolicy 是什么，什么时候必须设
referrerpolicy 控制 <a></a> 标签点击跳转时，HTTP 请求头中 Referer 字段是否发送、发什么内容。它不是装饰性属性，而是直接影响隐私暴露和资源加载行为的关键开关。比如你从 HTTPS 页面跳到 HTTP 页面，不设策略可能泄露原始 URL 路径；又或者跳转到第三方统计域名，对方能直接看到你站内哪个页面触发了这次点击。
常见错误现象：Referer 意外为空（导致目标站 403）、跳转后 analytics 数据丢失、CDN 回源失败（因 Referer 校验）。这些往往不是后端问题，而是前端 <a href="..." referrerpolicy="..."></a> 没配对或配错。
-
referrerpolicy只在跨源跳转时生效（同源下浏览器默认发完整 Referer，该属性被忽略） - 值为
"no-referrer"时，Referer头彻底不发送；"origin"只发协议+域名+端口，不带路径和查询参数 - 若未声明，浏览器按默认策略处理：HTTPS → HTTP 会清空 Referer（安全降级），HTTPS → HTTPS 则通常发完整 URL
5 种常用值的实际效果对比
不同取值对请求头和兼容性影响差异很大，不能凭名字猜行为：
-
"no-referrer"：请求头无Referer字段。适合跳转到不可信第三方或需隐藏来源的场景，但可能被目标站拒绝（如某些 API 要求 Referer 校验） -
"no-referrer-when-downgrade"（浏览器默认）：HTTPS→HTTP 不发 Referer；HTTPS→HTTPS 发完整 URL。绝大多数情况够用，但注意：它不防同协议下的路径泄露 -
"origin"：只发https://example.com，不带/admin/user?id=123。推荐用于跳转到 SaaS 工具、支付网关等需要来源识别但无需路径的场景 -
"origin-when-cross-origin"：同源跳转发完整 URL，跨源只发 origin。比"origin"更宽松，适合内部多子域系统（如app.example.com→api.example.com） -
"strict-origin-when-cross-origin"：最细粒度控制——HTTPS→HTTPS 跨源发 origin，HTTPS→HTTP 不发，HTTP→HTTP 发 origin。现代浏览器支持好，但 IE 完全不支持
与 meta 和全局 referrer 的关系
<meta name="referrer" content="..."> 是旧式全局设置，已被废弃（Chrome 85+ 忽略），且无法覆盖单个 <a></a> 的 referrerpolicy。也就是说：<a></a> 上的 referrerpolicy 优先级最高，会直接覆盖 <meta> 或 Referrer-Policy HTTP 响应头。
容易踩的坑：
- 误以为设了
<meta>就一劳永逸，结果个别链接仍泄露路径 - 在
<a></a>上写错大小写，比如referrerpolicy="Origin"（必须小写，否则无效） - 用
document.referrer测试时发现为空，其实这是 JS API 行为，和referrerpolicy无关——后者只影响 HTTP 请求头
实际调试方法
验证是否生效，不能靠猜，得看真实请求头：
- 打开 DevTools → Network → 点击对应跳转链接 → 找到跳转后的那个请求 → 查看 Request Headers 中是否有
Referer，值是什么 - 用 curl 模拟：执行
curl -H "Referer: https://a.com/path?q=1" https://b.com/对比有无referrerpolicy时的行为差异 - 注意：Firefox 开发者工具里
Referer头默认折叠，需右键列头勾选 “Referer” 才显示
复杂点在于，同一个页面里不同链接可能需要不同策略——比如跳支付页用 "origin"，跳外部博客用 "no-referrer"，而内部路由用默认即可。别试图用一个全局策略包打所有场景。
