referrerpolicy="no-referrer"仅对iframe内部主动请求生效，不影响父页面加载iframe时的referer；后者由父页面响应头referrer-policy决定，前端标签无效。
referrerpolicy="no-referrer"对iframe内部请求有效，但不隐藏父页面加载它的Referer
加 referrerpolicy="no-referrer" 到 <iframe></iframe> 标签上，只能让 iframe 里自己发起的请求（比如它内部的 <img src="https://ad.example.com/pixel.gif?x-oss-process=image/resize,p_40">）不带 Referer 头；父页面加载这个 iframe 时发出的 HTTP 请求，Referer 完全不受影响。
常见错误现象：给 <iframe src="https://widget.com/embed.js" referrerpolicy="no-referrer"></iframe> 加了属性，结果 widget 服务端日志里还是能看到完整父页面 URL——因为那是父页面请求 iframe 主文档时发的 Referer，不是 iframe 自己发的。
- 必须把
referrerpolicy直接写在<iframe></iframe>开始标签上，写在<div> 包裹层里无效 <li>该属性只作用于 iframe 内部脚本、图片、fetch() 等主动请求，不控制 iframe 自身的 HTML 文档加载行为</li> <li>验证是否生效，得在 Network 面板里找到 iframe 的主文档请求（即 <code>src指向的那个 URL），看它的 Request Headers 中Referer字段值，而不是看 iframe 里某张图片的请求 - 旧版 Safari（≤15.4）会忽略
referrerpolicy属性，但对响应头支持更稳定，建议后端统一配Referrer-Policy响应头 -
<meta name="referrer" content="origin">对 iframe 加载无效，它只影响后续 a 标签点击或表单提交 - Nginx 示例配置：
add_header Referrer-Policy "strict-origin-when-cross-origin"; - 必须后端配合，在父页面响应中设置
Referrer-Policy响应头，且值要匹配对方白名单规则（比如对方只认https://yoursite.com，你就不能用no-referrer） - 若对方允许 origin 级校验，用
origin或strict-origin-when-cross-origin更稳妥，比no-referrer兼容性更好 - 别指望
referrerpolicy能绕过服务端 Referer 校验逻辑——它只裁剪请求头，不改变请求本身 - 这种泄露无法用 HTML 属性解决，只能靠服务端限制 widget 访问权限（如 CSP 的
frame-ancestors）、或要求第三方使用 postMessage 通信并过滤敏感字段 - 若 widget 来自不可信域，
referrerpolicy对隐私保护几乎零作用，重点应放在隔离上下文（sandbox 属性）和通信机制上 - 测试时别只盯着 Network 面板的 Referer 字段，还得查 widget 是否在控制台打印了
window.parent.location
父页面加载iframe时的Referer由全局策略决定，不是referrerpolicy能管的
iframe 加载那一刻的 Referer，取决于父页面自身的 Referrer-Policy 配置优先级链：HTTP 响应头 Referrer-Policy > <meta name="referrer"> > 浏览器默认策略。你在 <iframe></iframe> 上设的 referrerpolicy 对它完全没用。
比如父页面响应头是 Referrer-Policy: no-referrer-when-downgrade，那么 HTTPS 页面加载 HTTPS iframe 时，Referer 就是完整 URL（含 ?token=abc 这类敏感参数）；如果改成 strict-origin-when-cross-origin，就只会发 https://your-site.com，路径和 query 全被裁掉。
第三方iframe要求“隐藏来源”时，仅前端加referrerpolicy基本没用
如果第三方 widget 明确说“请不要暴露你的页面地址”，那他们真正关心的是 iframe 主文档请求的 Referer，而不是 iframe 内部资源的 Referer。这时候只改前端标签毫无意义。
典型场景：广告平台、支付 SDK、客服浮窗等嵌入式服务，它们往往通过服务端校验 Referer 白名单。你前端加了 referrerpolicy="no-referrer"，但父页面没配响应头，对方照样拿到完整来源 URL。
iframe里JS读取window.parent.location不算Referer泄露，referrerpolicy管不了
很多第三方 widget 实际并不依赖 HTTP Referer 头，而是直接执行 window.parent.location.href 或 document.referrer 获取父页面地址。这种行为完全绕过所有 referrerpolicy 控制，浏览器也无权阻止。
常见错误现象：明明 iframe 加了 referrerpolicy="no-referrer"，widget 还是拿到了 https://your-site.com/admin/user/123?session=xyz —— 因为它是 JS 主动读的，不是服务器从请求头里拿到的。
