strict-origin-when-cross-origin不能用于meta name="referrer"，该标签仅支持no-referrer、origin、origin-when-cross-origin等有限枚举值；拼错或使用不支持的值（如strict-origin-when-cross-origin）会被浏览器静默忽略并退回到默认的no-referrer-when-downgrade。
strict-origin-when-cross-origin不是HTML meta能直接用的值
你在 <meta name="referrer"> 里写 content="strict-origin-when-cross-origin"，浏览器会静默忽略——这个值根本不在 meta 支持的枚举列表里。它只被 HTTP 响应头 Referrer-Policy 和 HTML 元素的 referrerpolicy 属性支持。meta name="referrer" 只认这几个：no-referrer、origin、origin-when-cross-origin、no-referrer-when-downgrade、unsafe-url。拼错或用错，一律退回到默认的 no-referrer-when-downgrade。
为什么origin-when-cross-origin是meta里最接近strict-origin-when-cross-origin的选项
虽然名字不同，但 origin-when-cross-origin 是 meta 中唯一能实现“同源发全路径、跨源只发 origin”的策略。它不处理 HTTPS→HTTP 降级场景（这点不如 strict-origin-when-cross-origin），但对绝大多数页面已足够安全：
- 点击跳转到同域页面 →
Referer: https://a.com/path?x=1 - 点击跳转到
https://b.com→Referer: https://a.com - 点击跳转到
http://b.com（降级）→Referer: https://a.com（仍发，这是风险点）
如果你真需要降级时清 Referer，必须靠后端响应头，meta 做不到。
meta设置后，JS跳转和fetch请求完全不受影响
meta name="referrer" 对以下行为零作用，这是最容易误判的地方：
-
window.location.href = "https://third-party.com"→ Referer 按浏览器默认策略发（通常是strict-origin-when-cross-origin） -
fetch("https://api.example.com", { method: "POST" })→ 默认发完整 Referer，除非显式加referrerPolicy: "origin-when-cross-origin" -
<iframe src="https://widget.com"></iframe>→ 即使页面设了meta，也必须单独加referrerpolicy="origin" - 用户右键“在新标签页中打开” → 浏览器直接忽略
meta，走自身策略
真正起效的安全平衡必须靠服务端响应头
只有 HTTP 响应头 Referrer-Policy: strict-origin-when-cross-origin 能覆盖全部请求类型：JS 请求、静态资源加载、错误页、首次访问、iframe、表单提交……Nginx 配置示例：
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
注意 always 参数，否则 4xx/5xx 页面不生效。前端 meta 最多只是兜底，且仅对 HTML 自动导航类请求有效——它不是安全方案的主力，而是补漏手段。
真正容易被忽略的是：第三方登录回调页、支付结果页、含临时 token 的跳转出口，这些页面哪怕只有一处 JS 跳转没配 referrerPolicy，就可能泄露敏感路径。安全不是设一个 meta 就完事，得逐层校验请求来源的每一环。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
