referrerpolicy是控制浏览器请求是否及如何发送referer头的策略，它不参与防盗链校验，也不能阻止资源被第三方加载；真正防盗链需服务端（如nginx）配置valid_referers或签名url来拦截非法referer请求。
referrerpolicy 是什么，为什么不能防盗链
referrerpolicy 控制的是浏览器发请求时是否携带 Referer 头、携带什么内容，它本身**不阻止资源加载**，也不校验来源域名。防盗链真正起作用的是服务端（比如 Nginx、CDN）对 Referer 请求头的检查和拦截。把 referrerpolicy 当成防盗链开关，是常见误解。
常见的 referrerpolicy 值及其实际影响
不同取值会改变浏览器发出的 Referer 内容，间接影响服务端能否识别合法来源：
-
no-referrer：完全不带Referer头 → 服务端收不到来源信息，可能被直接拒绝（尤其配置了valid_referers none的 Nginx） -
origin：只传协议+域名+端口（如https://a.com），不带路径 → 对静态资源（如图片、CSS）较友好，兼容多数防盗链规则 -
strict-origin-when-cross-origin（默认值）：同源传完整 Referer，跨域只传 origin → 行为最保守，但第三方 CDN 或 iframe 场景下 Referer 可能被截断 -
no-referrer-when-downgrade：HTTP→HTTPS 不带 Referer，其他情况照常 → 避免敏感路径泄露，但对防盗链无增强作用
怎么配才让防盗链“看起来生效”
关键不是前端配什么，而是前后端配合。前端配错反而会让合法请求被拒：
- 如果后端用 Nginx 的
valid_referers domain.com，前端必须确保跨域请求带上完整或至少是origin级别的 Referer → 推荐显式设referrerpolicy="origin" - 图片、字体等资源若从 CDN 加载，且 CDN 启用了 Referer 白名单，
referrerpolicy="no-referrer"会导致全部 403 - 不要在
<img>单独设referrerpolicy，而应在根<meta>统一控制：<meta name="referrer" content="origin">
（注意是name="referrer"，不是name="referrerpolicy"） - 现代写法支持
<meta referrerpolicy="origin">，但 IE 不识别，优先用name="referrer"兼容老版本
真正防盗链要查服务端日志和配置
前端改了 referrerpolicy 却还是 403？大概率问题不在这里：
- 检查 Nginx 是否开了
if ($invalid_referer) { return 403; }，并确认$invalid_referer是否包含你期望的来源 - 用浏览器开发者工具 → Network → 点开失败请求 → 查看 Request Headers 里有没有
Referer，值是什么 - CDN（如 Cloudflare、阿里云）的防盗链设置独立于 HTML，需单独配置白名单或关闭 Referer 校验
-
referrerpolicy对 fetch/AJAX 请求同样生效，但XMLHttpRequest默认不发送 Referer，需手动加referrerPolicy: 'origin'
referrerpolicy 是个“信号灯”，不是“门禁卡”。配得再准，门锁没装在服务端，就永远拦不住盗链。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
