最直接有效的做法是：对跳转链接加 rel="noreferrer"；对资源加载用 referrerpolicy 属性；全局策略优先用 HTTP 响应头 Referrer-Policy。
想控制 Referer 发送行为，最直接有效的做法是：对跳转链接加 rel="noreferrer"；对资源加载（如 <img alt="HTML怎么做Referrer Policy_html Referrer Policy来源策略设置【实用】" >、<script></script>）用 referrerpolicy 属性；全局策略优先走 HTTP 响应头 Referrer-Policy，而非 <meta>。
什么时候该用 rel="noreferrer" 而不是 referrerpolicy
只对 <a></a> 标签的跳转行为生效，且效果最强——它会彻底移除 Referer 请求头，同时自动附带 noopener（防 window.opener 劫持）。这和 referrerpolicy 的语义完全不同：referrerpolicy 是“怎么发”，而 rel="noreferrer" 是“不发”。
- 适用场景：用户点击外链跳转（尤其是敏感页、支付页、后台页）、广告链接、第三方推广链接
- 错误用法：写成
rel="nofollow"或rel="noopener"单独使用——前者不影响 Referer，后者不阻止 Referer - 注意：不能用于
<form></form>提交，该属性仅对<a></a>和<area>有效
referrerpolicy 属性在哪些标签上能用
支持的 HTML 元素包括：<img alt="HTML怎么做Referrer Policy_html Referrer Policy来源策略设置【实用】" >、<iframe></iframe>、<script></script>、<link>、<audio></audio>、<video></video>、<embed></embed>。但不支持 <a></a>（要用 rel）或 <form></form>（无标准控制方式）。
- 常见误配：
<a href="..." referrerpolicy="no-referrer"></a>—— 浏览器忽略该属性，毫无效果 - 局部优先级高于全局：比如页面设了响应头
Referrer-Policy: origin-when-cross-origin，但某个<img referrerpolicy="no-referrer" alt="HTML怎么做Referrer Policy_html Referrer Policy来源策略设置【实用】" >仍会按no-referrer执行 - 值选错风险：
unsafe-url会泄露完整 URL（含 query 参数），包括 token、user_id 等，生产环境禁止使用
HTTP 响应头 Referrer-Policy 和 <meta> 哪个更靠谱
服务端设置的响应头 Referrer-Policy 优先级最高，覆盖所有请求（含内联脚本发起的 fetch/fetch()、XMLHttpRequest），也覆盖 <meta> 和大部分标签属性。而 <meta name="referrer"> 是遗留方案，仅影响当前 HTML 文档后续发出的请求，且不被所有浏览器完全支持（如 Safari 对其处理较弱）。
立即学习“前端免费学习笔记（深入）”；
- 必须用响应头的场景：需要控制 JS 发起的跨域请求 Referer、统一管理全站策略、满足合规审计要求
- 避免混用：CSP 中的
referrer指令（如Content-Security-Policy: referrer no-referrer）会覆盖 HTML 中的<meta>，但不会覆盖响应头Referrer-Policy；若三者共存，顺序为：响应头 > CSP 指令 ><meta> - 兼容性提示：
strict-origin-when-cross-origin在 Chrome 85+、Firefox 79+、Safari 16.4+ 支持良好；老版本 Safari 可能降级为no-referrer-when-downgrade
调试时怎么看 Referer 到底有没有发出去
别猜，直接看 DevTools Network 面板里每个请求的 Request Headers —— 找 Referer 字段是否存在、值是什么。注意两个关键点：
- 如果字段完全缺失（不是空字符串），说明策略生效（如
rel="noreferrer"或referrerpolicy="no-referrer"） - 如果值是空字符串（
Referer:），可能是服务器主动清空，或某些中间件/CDN 干预，不代表前端策略成功 - 特别留意重定向链：第一次请求可能带 Referer，但 302 后的跳转请求是否还带，取决于跳转目标页自身的策略，不是源页面能控制的
真正容易被忽略的是：Referer 控制只作用于“出站”请求，对同域内导航、history.pushState、location.href 赋值等行为无效；另外，document.referrer 的值由上一个页面决定，前端无法通过任何属性修改它——它只是只读快照。
