referrerpolicy属性不是全站开关，仅对单个HTML元素触发的单次请求生效，不继承、不传递，且无法控制JS请求、iframe加载、form提交及window.location跳转；必须前后端分层配合（响应头+局部属性）才能平衡安全与功能。
直接结论：不能靠 HTML 单独平衡——referrerpolicy 属性只管单次请求，<meta name="referrer"> 仅影响后续导航，二者都覆盖不了 JS 请求、<iframe>、表单提交或跳转逻辑；真要平衡安全与功能，必须前后端分层配合。
为什么 referrerpolicy 属性不是“全站开关”
它只绑定在触发请求的那个 HTML 元素上，且仅生效一次。比如：<a href="https://evil.com" referrerpolicy="no-referrer"> 点击后，目标页的 <img src="/logo.png"> 仍会按自身策略发 Referer，跟父页无关。
-
referrerpolicy对window.location.href、location.replace()、<iframe>加载完全无效 -
<form>默认不继承页面级策略，必须显式写referrerpolicy="origin"才生效 - 若同时配置了 CSP 的
Content-Security-Policy: referrer no-referrer，CSP 会强制覆盖 HTML 中的referrerpolicy值 - 浏览器 DevTools Network 面板显示的 Referer 可能被缓存或重定向干扰，验证必须靠服务端原始日志（如
python3 -m http.server 8000）
什么时候该用 <meta name="referrer" content="...">
它只对当前 HTML 文档发起的**后续导航类行为**起作用：点击链接、表单提交（除非 <form> 显式设了 referrerpolicy）、<area> 跳转等。但它对 JS 发起的 fetch()、XMLHttpRequest、<img>、<script> 加载一律无效。
- 值为
origin：跨域时只发https://yoursite.com/，不带路径和参数，适合多数外链场景 - 值为
strict-origin-when-cross-origin：同域发完整 URL，跨域只发源，且 HTTPS→HTTP 时自动清空——这是目前隐私与功能最稳妥的折中点 - 不要设
unsafe-url：它会让所有请求（包括降级请求）都发完整 URL，极易泄露 token、sessionID 等敏感参数 - 该标签优先级低于 HTTP 响应头
Referrer-Policy，后端配了头，<meta>就会被忽略
为什么必须搭配后端 Referrer-Policy 响应头
<meta> 和 referrerpolicy 属性都管不到脚本请求、错误页、静态资源加载、以及用户从搜索引擎点击进来的首次访问。只有响应头能覆盖全部。
立即学习“前端免费学习笔记（深入）”；
- Nginx 中推荐统一加：
add_header Referrer-Policy "strict-origin-when-cross-origin" always;——always确保 4xx/5xx 页面也生效 - 别用
no-referrer-when-downgrade：它是默认值，但跨域时仍发完整 URL，风险高；strict-origin-when-cross-origin才真正隐藏路径和查询参数 - 若用 Nginx Proxy Manager，改模板文件（如
_hsts.conf）比在每个 HTML 里塞<meta>更可持续 - IE11 不支持
<meta name="referrer">，但支持响应头，所以响应头是兜底保障
真正容易被忽略的三层断裂点
Referer 控制从来不是“设一个值就万事大吉”的事。你必须意识到三处天然断裂：
-
rel="noreferrer"只管<a>标签点击，对<form>、<iframe>、JS 跳转无效，但它能彻底清空 Referer 且隐式启用noopener，是唯一前端可控的强制手段 -
referrerpolicy属性不继承、不传递，新页面的 Referer 行为由它自己的响应头或<meta>决定，不是你父页说了算 - 后端校验（如防盗链、CSRF）绝不能依赖 Referer 是否存在——它可被伪造、可被浏览器策略清空、也可被代理抹掉，必须用
SameSiteCookie、CSRF Token 等可靠机制替代
