优先设strict-origin-when-cross-origin，它同域发完整URL、跨域只发origin、HTTPS→HTTP降级时清空，隐私与功能平衡最佳；no-referrer最严但破坏分析逻辑，慎用。
直接结论：优先设 strict-origin-when-cross-origin，它在隐私、兼容性和功能间取得最佳平衡；no-referrer 最严但会破坏部分分析和跳转逻辑，慎用。
哪些 Referrer-Policy 值真正可用且浏览器支持好
目前所有主流浏览器（Chrome 86+、Firefox 90+、Safari 15.4+、Edge 92+）稳定支持的值共 7 个，unsafe-url 和空字符串虽被识别但不推荐：
• no-referrer：彻底清空 Referer 头，同域/跨域都不发
• no-referrer-when-downgrade：默认值，HTTPS→HTTP 时清空，其余照发完整 URL
• origin：一律只发协议+域名+端口，如 https://example.com
• origin-when-cross-origin：同域发完整 URL，跨域只发 origin
• same-origin：仅同源请求带 Referer，跨域完全不带
• strict-origin：跨域时只发 origin，且 HTTPS→HTTP 降级时清空
• strict-origin-when-cross-origin：同域发完整 URL；跨域只发 origin；HTTPS→HTTP 降级时也清空 —— 这是当前最实用的选项
HTML 中怎么设 referrerpolicy 属性才生效
这个属性只对特定 HTML 元素发起的请求起作用，不是全局策略：
• 有效元素包括：<a>、<img>、<iframe>、<script>、<link>、<audio>、<video>
• 必须写在对应标签内，例如：<a href="https://thirdparty.com" referrerpolicy="origin">跳转</a>
• 它不能控制 JS 发起的 fetch() 或 XMLHttpRequest 请求，那些由响应头统一管
• 如果同时存在响应头 Referrer-Policy 和元素级 referrerpolicy，后者优先级更高（仅对该元素生效）
为什么不能只靠 HTML 属性，必须配响应头
前端加 referrerpolicy 是补位，不是主力：
• 页面中所有资源加载（CSS、JS、字体、图片）默认走响应头策略，不受单个元素控制
• 用户点击链接跳转时，referrerpolicy 确实能起效，但无法覆盖页面内脚本自动发起的请求（比如埋点 SDK 的上报）
• 后端设置的 Referrer-Policy 响应头（如 Nginx 的 add_header Referrer-Policy "strict-origin-when-cross-origin";）会强制应用于该响应下所有子资源请求
• 更关键的是：JS 无法修改或绕过响应头策略，而 HTML 属性可被动态 JS 改写，可靠性低
立即学习“前端免费学习笔记（深入）”；
容易踩的坑：unsafe-url 和 rel="noreferrer" 的混淆
unsafe-url 是唯一明确禁止的值：
• 它会让完整 URL（含路径、查询参数）无条件发送，哪怕从 HTTPS 页面跳到 HTTP 站点
• 比如 https://app.com/admin?token=abc → http://tracker.com，明文泄露 token
• 所有现代审计工具（Lighthouse、CSP Evaluator）都会标红警告
• rel="noreferrer" 不是 Referrer-Policy 值，而是 <a> 的独立属性，效果等价于 referrerpolicy="no-referrer"，但额外禁用 window.opener，防反向控制 —— 对外链更安全，建议优先用它代替 referrerpolicy="no-referrer"
