<meta name="referrer"> 实际作用极小，仅对HTML解析完成后由原生标签触发的导航请求生效，对JS请求、右键新标签页、首次访问、静态资源加载等场景完全无效。
只在 <meta name="referrer"> 里设策略，根本没法真正控制 Referer —— 它既管不住 JS 请求，也拦不了右键新标签页，更对首次访问和静态资源加载无效。
为什么 <meta name="referrer"> 实际作用极小
这个标签只在页面解析完成后、由 HTML 自动触发的导航类请求中生效，比如用户点击未显式设策略的 <a>、提交没写 referrerpolicy 的 <form>、或加载 <img src>。但它对以下场景完全不生效：
-
fetch()、XMLHttpRequest、动态插入的<script>或<img> - 页面初始加载时自动拉取的 CSS/JS/字体等资源（此时
<meta>还没解析） - 用户右键“在新标签页中打开链接”——浏览器直接忽略该 meta，走自身默认策略
- 从搜索引擎点击进来的首次访问——服务端响应头已发完，
<meta>根本没机会执行 -
window.location.href = "https://xxx"或location.replace()—— 完全无视
referrerpolicy 属性必须写在具体元素上，且只生效一次
它不是全局开关，不能写在 <head> 里就一劳永逸。每个支持的元素都得单独加，而且只裁剪「这一次请求」的 Referer：
-
<a href="https://target.com" referrerpolicy="no-referrer">：仅这次点击不带 Referer；目标页里所有后续请求照常按自己策略发 -
<img src="https://cdn.com/photo.jpg" referrerpolicy="origin">：可防图床因 Referer 不匹配返回 403，但若 CDN 强制校验完整 URL，还得配服务端白名单 -
<form action="/api/submit" referrerpolicy="origin">：必须显式写，否则表单提交仍走默认no-referrer-when-downgrade，可能泄露?token=xxx -
<iframe src="https://third-party.com" referrerpolicy="strict-origin-when-cross-origin">：父页面任何设置都不影响 iframe 加载，必须写在<iframe>标签上
值大小写敏感：no-referrer 有效，No-Referrer 或 no_referrer 直接被浏览器静默忽略。
立即学习“前端免费学习笔记（深入）”；
和响应头 Referrer-Policy 冲突时谁起效
后端响应头优先级永远高于 HTML 级配置。也就是说：
- 如果服务端返回了
Referrer-Policy: strict-origin-when-cross-origin，那么<meta name="referrer">和所有未显式设referrerpolicy的元素都会被覆盖 -
referrerpolicy属性仍可 override 单个元素的请求行为，但它只对那个元素生效，且无法绕过响应头对脚本请求、资源加载的统一控制 - CSP 中的
Content-Security-Policy: referrer no-referrer会强制覆盖 HTML 中的referrerpolicy值
真正起效的配置必须从后端响应头开始
前端所有 HTML 级控制都是补位，响应头才是主力。验证是否真生效，别信 DevTools Network 面板——它可能被缓存或重定向干扰。可靠方式是让目标服务端打印原始请求头：
- 起一个本地接收服务：
python3 -m http.server 8000 --bind 127.0.0.1:8000 - 测试页放带策略的链接，点击后观察终端输出：
Referer:行为空或缺失才算成功 - 注意降级场景：HTTPS → HTTP 时，
no-referrer-when-downgrade也会导致 Referer 不发，容易误判
最容易被忽略的是：即使你把所有 HTML 元素都加上 referrerpolicy="no-referrer"，只要服务端没配响应头，fetch()、XMLHttpRequest、以及页面首次加载的 JS/CSS 请求，依然按浏览器默认策略发 Referer。
