真正起效的只有后端referrer-policy响应头，html的标签和referrerpolicy属性仅作边缘补充，且优先级低、作用范围有限；必须通过服务器配置全局生效，并确保cdn/waf等中间层不覆盖。
只在 <meta name="referrer"> 里配策略根本不管用
这个标签只影响后续「用户主动导航」行为，比如点击链接、提交没设策略的 <form></form>，但对所有 JS 发起的请求（fetch()、XMLHttpRequest）、页面加载时自动拉取的 CSS/JS/字体、右键“在新标签页打开”、搜索引擎首次跳转，全部无效。
更关键的是：如果后端已返回 Referrer-Policy 响应头，浏览器会直接忽略这个 <meta> ——它优先级最低，纯属补位。
-
window.location.replace()和window.location.assign()完全不读它 - 哪怕写了
<meta name="referrer" content="no-referrer">，CDN 加载的图片依然带完整 Referer - 用户从百度搜索结果点进来时，该 meta 还没执行，策略形同虚设
referrerpolicy 属性必须逐个元素写，且只管单次请求
它不是全局开关，不能写在 或父容器里就一劳永逸。每个支持的标签都得单独加，而且只裁剪「这一次请求」的 Referer：
-
<img src="https://cdn.com/photo.jpg?x-oss-process=image/resize,p_40" referrerpolicy="origin">只让这张图发 origin，下一张图还得再写 -
<form action="/api/submit" referrerpolicy="origin"></form>必须显式声明，否则默认走no-referrer-when-downgrade，可能把?token=abc123暴露出去 -
<iframe src="https://third.com/embed" referrerpolicy="strict-origin-when-cross-origin"></iframe>才能控制 iframe 向外发请求时的 Referer，父页面任何设置都无效 - 值严格大小写敏感：
no-referrer有效，No-Referrer或no_referrer直接被浏览器当无效值丢弃
真正起效的只有后端 Referrer-Policy 响应头
前端所有 HTML 级控制都是边缘补充，响应头才是主力。它覆盖本域发起的所有请求类型：JS 的 fetch()、<script src></script>、<link rel="stylesheet">、甚至 <video></video> 加载。
推荐配置：Referrer-Policy: strict-origin-when-cross-origin，但必须加 always 参数确保错误页也生效：
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
原因很实际：
- 跨域时只发
https://example.com，不带路径和查询参数，防泄露/admin?session=xxx - 同源时仍发完整 URL，不影响前端路由或内部统计逻辑
- 加
always是为了覆盖 4xx/5xx 错误页——否则报错时 Referer 可能裸奔 - 不建议用
no-referrer：它会破坏很多依赖 Referer 的正常功能，比如 CDN 白名单校验、来源统计、CSRF 防御辅助判断
别把 Referrer-Policy 当 CSRF 主防线
Referer 可被伪造，Origin 头也可能缺失（比如某些 POST 表单提交），所以仅靠它防 CSRF 是危险的。
真实业务中必须组合使用：
- 服务端必须验证
Origin或Referer（仅作辅助，非唯一依据） - 关键操作强制要求
SameSite=Strict或LaxCookie - 敏感接口必须携带一次性
CSRF token，且服务端校验 -
Referrer-Policy的核心价值是隐私保护，不是替代 CSRF 防御机制
最容易被忽略的一点：策略生效依赖整个链路——你配了响应头，但 CDN、反向代理、WAF 层如果覆盖或清除了该头，就等于没配。上线前务必用 curl -I 或 DevTools Network 面板确认最终响应里确实存在且值正确。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
