必须写在内且越靠前越好，浏览器解析到即生效，后续动态插入无效；它仅控制页面自动发起的资源请求（如、等），不作用于fetch()、xmlhttprequest或用户手动操作。
meta name="referrer" 应该放在哪里？
必须写在 内，且越靠前越好 —— 浏览器解析到它就开始应用策略，后面动态插入的 <meta name="referrer"> 大概率被忽略。
它只影响页面**后续自动发起的请求**：比如 <img>、<script></script>、<iframe></iframe>、<link rel="stylesheet">、CSS 中的 @import 等。不控制 fetch()、XMLHttpRequest 或用户右键“在新标签页打开”这类行为。
- 错误做法：
里加，或用 JS 动态document.head.appendChild() - 正确写法：
<meta name="referrer" content="origin-when-cross-origin">放在<title></title>后面、其他资源标签前面
content 值选哪个？关键看同源/跨域和协议降级
可用值是固定枚举，不是自由字符串。常见组合行为如下：
-
no-referrer：所有请求都不带 Referer —— 最严，适合登录页、支付页等高敏场景 -
origin-when-cross-origin：同源发完整 URL（如https://a.com/page?x=1→https://a.com/page2），跨域只发源（https://a.com）—— 平衡安全与分析需求，推荐作为多数页面默认值 -
no-referrer-when-downgrade：HTTPS → HTTP 不发，其余都发完整 URL —— 浏览器默认值，但容易泄露路径参数（如?token=abc） -
origin：一律只发源（https://a.com/）—— 简单粗暴，适合不想暴露任何路径的静态站点
注意：strict-origin-when-cross-origin 虽更安全（HTTPS→HTTP 完全不发），但 Safari 15.4 之前兼容性差；unsafe-url 始终发完整 URL，有泄漏风险，线上应避免。
和 referrerpolicy 属性冲突时谁生效？
元素级 referrerpolicy 优先级高于 <meta name="referrer">。也就是说，<meta> 是兜底策略，个别资源可覆盖。
- 例如：全局设了
<meta name="referrer" content="origin">，但某个埋点<img src="log.gif" referrerpolicy="no-referrer">，那这张图确实不会发 Referer —— 这不是 bug，是设计如此 - 反过来，如果只靠
<meta>控制，却给某个外链<a href="https://evil.com"></a>加了rel="noreferrer"，那点击时 Referer 和window.opener都会被清掉，比referrerpolicy="no-referrer"更彻底
真正要管住 Referer，得同时考虑三处：<meta>（静态资源）、元素属性（单点覆盖）、JS 请求的 referrerPolicy 选项（动态请求）。
为什么开了 meta 还是看到 Referer 泄露？
最常被忽略的两点：
-
<meta name="referrer">对fetch()和XMLHttpRequest**完全无效** —— 这些必须显式传{referrerPolicy: "origin-when-cross-origin"} - 用户手动操作（如右键“在新标签页中打开链接”）走浏览器默认策略，不受
<meta>影响；若需控制，必须给<a></a>加rel="noreferrer"或referrerpolicy="no-referrer"
调试时直接看浏览器 Network 面板的请求头，别只信文档描述。不同浏览器对 strict-* 类策略支持仍有差异，生产环境建议用 origin-when-cross-origin 或 no-referrer-when-downgrade 并实测验证。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
