referrerpolicy不是全局开关，必须加在具体发起请求的HTML标签上且仅对单次请求生效；支持标签包括、、、、、等主动发请求的元素，不支持、等静态标签。
直接说结论：referrerpolicy 不是写在 里就全局生效的开关，它必须加在**具体发起请求的 HTML 标签上**，且只管那一次请求——想靠它“一劳永逸”控制所有跳转或资源加载，注定失败。
哪些标签能用 referrerpolicy？
只有会主动发 HTTP 请求的元素才支持该属性。常见有效位置包括：
-
<a></a>：控制点击跳转时的 Referer（但效果不如rel="noreferrer"彻底） -
<img alt="html怎么做referrerpolicy引用_html referrerpolicy引用来源策略控制【从零开始】" >、<script></script>、<link>、<iframe></iframe>：控制资源加载请求的 Referer -
<form></form>：控制表单提交时的 Referer（<meta name="referrer">对它无效）
无效场景：<div>、<code><span></span>、<button></button>（除非它触发了 JS 的 fetch()，但那得用 JS 的 referrerPolicy 选项）；<meta name="referrer"> 也不能替代它。
referrerpolicy="no-referrer" 为什么有时还看到 Referer？
这不是 bug，是机制使然：
立即学习“前端免费学习笔记（深入）”；
- 它只裁剪「当前这一次请求」的 Referer 头，新页面自己发起的请求（比如它的
<img src alt="html怎么做referrerpolicy引用_html referrerpolicy引用来源策略控制【从零开始】" >）按它自己的策略走，跟你原页面无关 - 用户右键“在新标签页打开”链接时，浏览器忽略
referrerpolicy，改用默认策略或响应头值 - 如果服务端返回了
Referrer-Policy响应头，且值不是no-referrer，它可能覆盖局部设置（no-referrer是少数几个能强制胜出的值） - 旧版 Safari（≤15.4）压根不支持该属性，直接降级为浏览器默认行为
和 rel="noreferrer" 到底怎么选？
二者目标相似，但作用域和强度不同：
-
rel="noreferrer"只对<a></a>生效，但效果最强：彻底不发 Referer，且隐式启用noopener，防window.opener劫持 -
referrerpolicy="no-referrer"能用于<img alt="html怎么做referrerpolicy引用_html referrerpolicy引用来源策略控制【从零开始】" >、<form></form>、<iframe></iframe>等，但对<a></a>的控制弱于rel="noreferrer" - 实际组合更可靠：
<a href="https://pay.example.com" rel="noreferrer"></a>用于支付跳转；<form action="/api/submit" referrerpolicy="origin"></form>用于敏感接口提交
别把 rel="nofollow" 或 rel="noopener" 单独当 Referer 控制手段——它们完全不影响 Referer 行为。
值选错的典型后果
策略值不是随便填的字符串，大小写敏感、浏览器兼容性差、语义混淆都会翻车：
-
unsafe-url：强制发完整 URL（含?token=abc），生产环境禁用；Chrome DevTools 里看到它被标红警告不是偶然 -
same-origin或strict-origin：在<img alt="html怎么做referrerpolicy引用_html referrerpolicy引用来源策略控制【从零开始】" >上基本无效，浏览器会悄悄降级为no-referrer-when-downgrade -
origin-when-cross-origin和strict-origin-when-cross-origin看似接近，但后者在 HTTPS→HTTP 时完全不发 Referer，前者仍可能发源——这点在跳转到 HTTP 第三方页时就是隐私漏洞 - 大小写写成
No-Referrer或no_referrer：浏览器直接忽略，当成没设
真正难的不是写对那一行属性，而是理清「谁在什么时候、向谁、发什么 Referer」——这需要同时看响应头、<meta>、元素属性、JS 请求选项，再结合服务端日志验证，缺一不可。
