<meta name="referrer"> 对外部资源加载无效，因其仅作用于导航类行为；控制 Referer 必须为每个资源标签单独设置 referrerpolicy 属性，或通过响应头 Referrer-Policy 统一配置。
只在 <meta name="referrer"> 里设策略，对外部资源引用基本没用——它不控制 <img>、<script>、<link> 加载时的 Referer，更不管 JS 发起的 fetch() 或 XMLHttpRequest。
为什么 <meta name="referrer"> 对外部资源加载完全失效
这个标签只在页面解析完成、由 HTML 自动触发的「导航类行为」中起作用，比如用户点击链接、未显式设策略的 <form> 提交。但所有外部资源（CSS/JS/字体/<img>）都是浏览器在解析 HTML 过程中**同步发起的请求**，此时 <meta> 尚未生效或已被忽略。
- 常见错误现象：CDN 图片返回
403 Forbidden，因为 Referer 带了完整路径，而 CDN 只校验origin - 第三方统计脚本因 Referer 被截断，上报失败或漏埋点
- 页面一打开就发出去的
<script src="https://cdn.com/analytics.js">仍带敏感参数
referrerpolicy 属性必须写在每个资源标签上
要真正控制跨域资源请求的 Referer，必须把 referrerpolicy 直接加在对应元素上，且值大小写敏感、拼错即退化为默认策略 no-referrer-when-downgrade。
-
<img src="https://cdn.com/photo.jpg" referrerpolicy="origin">——防止图床因 Referer 不匹配拒绝服务 -
<script src="https://cdn.com/lib.js" referrerpolicy="strict-origin-when-cross-origin">——同域保留路径用于调试，跨域只发origin -
<link rel="stylesheet" href="https://fonts.googleapis.com/css2" referrerpolicy="no-referrer">——字体请求常被origin校验，清空最稳妥 -
<iframe src="https://embed.example.com/widget" referrerpolicy="origin-when-cross-origin">——控制 iframe 内部向第三方发请求时的 Referer，不是父页面向它发的
JS 请求（fetch/XMLHttpRequest）必须靠响应头或调用时指定
fetch("https://api.example.com") 完全无视 <meta> 和所有 HTML 属性。Referer 行为由两处决定：
立即学习“前端免费学习笔记（深入）”；
- 后端响应头
Referrer-Policy: strict-origin-when-cross-origin（推荐，覆盖全部请求） - 前端调用时传
referrerPolicy选项：fetch(url, { referrerPolicy: 'no-referrer' }) - 注意：
XMLHttpRequest不支持该选项，只能依赖响应头
防盗链不能靠 <meta name="referrer"> 实现
它只影响「自己发不发、发多少」，对「别人怎么请求你」毫无约束力。盗链者可随意伪造或清空 Referer 头，浏览器也不会拦。
- 第三方网站用
<img src="your-cdn.com/secret.jpg">盗图时，Referer 是他们的域名，<meta>对此无感知、无干预能力 - 真正防盗链必须依赖服务端校验：
Nginx valid_referers+$invalid_referer，或签名 URL（如/img/123.jpg?expires=1717905600&sig=abc123） - 若 CDN 已配置
Referrer-Policy响应头，<meta>会被直接忽略——优先级最低
最容易被忽略的是：静态资源加载发生在 DOM 构建极早期，<meta name="referrer"> 的时机和作用域都错位了；而 referrerpolicy 属性又只对单次请求生效，不继承、不传递——这意味着每个外链资源都得单独处理，漏一个就可能泄露敏感路径或参数。
