referrerpolicy="no-referrer" 仅对当前元素触发的单次请求生效，不继承、不传递，新页面后续请求仍按自身策略发送 Referer；它对 window.location 跳转、<iframe> 加载和未显式设置的表单提交无效，验证须通过服务端原始请求头确认。
referrerpolicy 属性不是“开关”，而是对单次请求的 Referer 头做即时裁剪——加了它，不等于全站隐身；没加它，也不代表信息全量泄露。它的效果严格绑定在触发请求的那个元素上，且只生效一次。
referrerpolicy="no-referrer" 为什么点开链接后新页面里 still 有 Referer？
因为 referrerpolicy 不继承、不传递。它只管当前元素发起的那一次请求（比如点击一个 <a> 标签），不管新页面后续自己发的任何请求（如新页面里的 <img>、fetch() 或自动跳转）。
- 新页面是否带 Referer，取决于它自己的
<meta name="referrer">、HTTP 响应头Referrer-Policy，或其中每个资源标签是否单独设置了referrerpolicy -
window.location.href = "https://example.com"和location.replace()完全无视该属性，不会触发 Referer 控制 -
<iframe>加载不受父页面任何referrerpolicy影响，必须在<iframe>标签上显式设置
form 提交必须显式加 referrerpolicy 才生效
<form> 默认行为和链接不同：即使页面全局设了 <meta name="referrer" content="origin">，表单提交仍按浏览器默认策略（no-referrer-when-downgrade）走，除非你在 <form> 标签上直接写：
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
<form action="/submit" method="POST" referrerpolicy="origin">
- 仅影响该表单的
submit请求，不影响其内部<input type="image">或<button formaction>的独立行为 - 若同时设置了 CSP 的
Content-Security-Policy: referrer no-referrer，CSP 会覆盖 HTML 中的referrerpolicy属性 -
rel="noreferrer"对<a>有效，但对<form>无效——别混用
验证 referrerpolicy 是否真生效，别信开发者工具 Network 面板
Network 面板显示的 Referer 头可能被 DevTools 自身逻辑伪造或缓存干扰，尤其在跨协议（HTTPS → HTTP）或重定向链中。真正可靠的验证方式是让目标服务端直接打印原始请求头：
立即学习“前端免费学习笔记（深入）”；
- 起一个本地接收服务：
python3 -m http.server 8000 --bind 127.0.0.1:8000 - 测试页放带策略的链接：
<a href="http://127.0.0.1:8000/test" referrerpolicy="no-referrer">test</a> - 点击后观察终端输出 —— 如果没有
Referer:行，或该行为空，才算成功 - 注意降级场景：
https://site.com→http://127.0.0.1:8000时，no-referrer-when-downgrade也会导致 Referer 缺失，别误判为no-referrer生效
最常被忽略的一点：referrerpolicy 是「请求发起侧」的策略，它无法约束目标网站是否记录、转发或滥用收到的 Referer —— 它只决定你这一端发什么、不发什么。而真实世界里，中间代理、CDN、甚至某些浏览器扩展都可能篡改或补全 Referer，所以关键路径上的敏感跳转（如含 token 的 URL），光靠这个属性不够，得配合后端校验或短期 token 机制。
