meta name="referrer" 对第三方盗链完全无效，因其仅控制本页发起请求的referer发送行为，无法约束第三方直接嵌入资源；真正防盗链需服务端配置valid_referers或签名url。
meta name="referrer" 对第三方资源防盗链完全无效，它不参与任何防盗链校验，也不能阻止别人加载你的资源。
为什么 meta name="referrer" 不能解决第三方盗链问题
防盗链本质是服务端检查请求头中的 Referer 字段是否合法，并据此返回 403 或重定向。而 <meta name="referrer" content="no-referrer"> 只影响「当前页面发起的后续请求」是否发送 Referer，比如点击链接、提交表单——但它对第三方网站直接嵌入 <img src="your-cdn.com/photo.jpg"> 这类请求毫无约束力。
常见错误现象：
- 加了
<meta name="referrer" content="no-referrer">后，自己页面里引用 CDN 图片正常，但别人仍能照常盗链 - 第三方网站用
curl -H "Referer: https://evil.com" your-cdn.com/photo.jpg直接请求，照样成功 - 浏览器控制台看到图片 403 报错，误以为是自己 Referer 没设好，其实是对方服务端拦截了你页面的 Referer，和你 meta 设置无关
referrerpolicy 属性在 <img> 等标签上的真实作用
这个属性只控制「该标签发起的请求」是否带 Referer，且仅对当前页面内该元素生效。它不是防盗链开关，而是隐私泄露控制开关。
典型使用场景：
- 用户在隐私页（如支付结果页）查看外部广告图，用
<img src="ad.example.com/btn.jpg" referrerpolicy="no-referrer">防止把/pay/success?token=abc这种敏感路径发给广告商 - 嵌入第三方统计脚本时，用
<script src="analytics.js" referrerpolicy="origin"></script>只发源站，不发完整 URL - 注意：
referrerpolicy="same-origin"对跨域<img>实际等效于no-referrer，因为浏览器根本不会发 Referer，反而可能让服务端防盗链规则收不到有效值而误放行
真正起防盗链作用的是服务端配置，不是前端 meta 或属性
前端所有 Referrer 控制手段都只是“减少信息泄露”，不是“阻止访问”。能真正拦住盗链的只有后端逻辑：
- Nginx 中必须配
valid_referers+$invalid_referer判断，例如：location ~ \.(jpg|png|gif)$ {<br> valid_referers none blocked *.mydomain.com;<br> if ($invalid_referer) { return 403; }<br>} - CDN 厂商（如 Cloudflare、阿里云 CDN）需开启「Referer 黑白名单」功能，不能只依赖源站响应头
- 对高敏感资源（如用户头像、凭证图），应弃用 Referer 校验，改用签名 URL：例如
/avatar/123.jpg?expires=1717905600&sig=abc123，过期即失效，且无法伪造
容易被忽略的一点：即使你把所有前端策略都设成 no-referrer，只要服务端没做校验，盗链就依然畅通无阻；反过来，哪怕你前端一个策略都没设，只要服务端 valid_referers 配得严，盗链照样 403。前后端职责不能倒置。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
