referrerpolicy属性必须加在发起请求的HTML标签上，仅对当前标签触发的单次请求生效，不继承、不传递；支持的标签包括、<img>、<script>、<link>、<iframe>、<form>等主动发起网络请求的元素。
referrerpolicy 属性必须加在发起请求的 HTML 标签上，不是写在 <head> 里就全局生效——它只管那个标签触发的单次请求。
哪些 HTML 标签能用 referrerpolicy？
只有会主动发起网络请求的元素才支持该属性，常见可设位置包括：
-
<a>：控制点击跳转时的 Referer -
<img>、<script>、<link>（如预加载）、<iframe>：控制资源加载时的 Referer -
<form>：控制表单提交时的 Referer（注意：<meta name="referrer">对它无效）
容易踩的坑：<meta name="referrer" content="origin"> 只影响后续导航（比如用户点链接或提交未显式设策略的表单），对 fetch()、动态插入的 <img>、window.location 跳转完全不起作用。
referrerpolicy="no-referrer" 为什么新页面仍有 Referer？
因为该属性不继承、不传递，只裁剪「当前这一次请求」的 Referer 头。新页面自己发的请求（比如它内部的 <img src="..."></img> 或 fetch()）按它自己的策略走——可能是响应头里的 Referrer-Policy，也可能是它自己写的 <meta>，跟你原页面加没加 referrerpolicy 没关系。
立即学习“前端免费学习笔记（深入）”；
验证是否真生效，别信开发者工具 Network 面板里显示的 Referer 值（它可能被缓存或重定向干扰）。最可靠方式是让目标服务端打印原始请求头，例如用 python3 -m http.server 8000 接收请求，看终端输出有没有 Referer: 行。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
rel="noreferrer" 和 referrerpolicy="no-referrer" 有什么区别？
二者效果不同，适用场景也不同：
-
rel="noreferrer"只对<a>生效，且是“彻底不发”，不是“发空值”；同时隐式启用noopener，防window.opener劫持 -
referrerpolicy="no-referrer"作用范围更广（<img>、<script>、<form>等都支持），但对<a>的效果不如rel="noreferrer"彻底（比如右键“在新标签页打开”仍可能走浏览器默认策略） -
<form>不支持rel，必须用referrerpolicy
所以实际组合常用：<a href="https://evil.com" rel="noreferrer"> 用于外链跳转；<form action="/api" referrerpolicy="origin"> 用于敏感接口提交。
strict-origin-when-cross-origin 和 no-referrer-when-downgrade 怎么选？
关键差异在「协议降级」和「跨源」两个维度是否发送路径与查询参数：
-
no-referrer-when-downgrade（默认）：HTTPS → HTTP 不发 Referer；HTTPS → HTTPS 或 HTTP → HTTP 都发完整 URL（含路径和参数） -
strict-origin-when-cross-origin（推荐）：同源发完整 URL；跨源只发 origin（如https://a.com）；HTTPS → HTTP 完全不发
举例：从 https://shop.example.com/checkout?uid=123&token=abc 跳到支付网关，用后者能避免把 token 泄露出去；前者则大概率泄露。注意：如果后端已配了 Referrer-Policy: strict-origin-when-cross-origin 响应头，它会覆盖 HTML 中的 referrerpolicy 属性（除非被 CSP 的 referrer 指令再覆盖）。
真正难的不是选哪个值，而是记住：每个标签独立生效、不继承、不传递；验证必须靠服务端日志，不能只看 DevTools；CSP 的 referrer 指令优先级最高，容易被忽略。
