标签设置x-frame-options完全无效，浏览器根本不支持；真正起效的只有服务端http响应头：x-frame-options或content-security-policy的frame-ancestors指令，后者优先级更高、更灵活。
meta 标签在 index.html 中无法真正阻止 iframe 嵌套，它只是个无效的 fallback。
浏览器对 meta 设置的 X-Frame-Options **完全不支持**——所有主流浏览器（Chrome、Firefox、Safari、Edge）均忽略该写法。你加了 ``，页面照样能被嵌入，控制台也不会报错，但防护形同虚设。
别浪费时间调试这个标签。它不是“兼容性差”，而是根本没被实现。
为什么 document.referrer 不能用于判断嵌入来源
很多开发者想靠 document.referrer 区分“谁嵌了我的页面”，结果发现：
-
document.referrer在跨域 iframe 中为空字符串（同源时才可能有值） - 父页可主动设置
referrerpolicy="no-referrer"，直接抹掉来源 - 攻击者用
srcdoc内联加载你的页面时，referrer永远是空 - HTTP 请求头中的
Referer可伪造，JS 层面无从验证真伪
所以任何基于 referrer 做白名单跳转的逻辑（比如“只允许 test.com 嵌入”）在真实攻击场景下极易绕过，且会误伤合法内嵌（如企业内网多个子域共用平台）。
window.top !== window.self 的执行时机和 sandbox 限制
这段 JS 检测本身有效，但能否执行成功，取决于父页面是否允许脚本运行：
- 若父页 iframe 带
sandbox="allow-scripts"：检测代码能跑，但重定向可能被拦截（如父页监听beforeunload或覆盖top.location） - 若父页 iframe 带
sandbox="allow-scripts allow-same-origin"：这是高危组合，检测代码能跑，但重定向后仍可被父页用contentWindow直接读取 DOM —— 沙箱已失效 - 若父页 iframe 带完整沙箱（如
sandbox=""）或未开allow-scripts：你的 JS 根本不会执行，检测逻辑直接被跳过
也就是说：window.top !== window.self 只能作为辅助提示，不能当作安全边界。它必须放在 最顶部，且要包裹 try/catch 防止因权限问题抛错中断后续逻辑。
真正起效的防线只有服务端响应头
唯一不可绕过、浏览器强制执行、无需 JS 支持的方案，是服务端返回正确的 HTTP 头：
-
X-Frame-Options: DENY—— 兼容 IE8+ 和所有现代浏览器，简单粗暴 -
Content-Security-Policy: frame-ancestors 'none'—— Chrome 39+/Firefox 34+/Edge 12+ 均支持，优先级高于X-Frame-Options - 两者同时配置最稳妥：旧浏览器走
X-Frame-Options，新浏览器按更严格的frame-ancestors执行
Nginx 示例（必须加 always 参数，否则 304 响应不带该头）：
add_header X-Frame-Options "DENY" always;<br>add_header Content-Security-Policy "frame-ancestors 'none';" always;
注意：frame-ancestors 'none' 和 X-Frame-Options: DENY 效果等价，但前者不支持单引号外的双引号写法，写成 "frame-ancestors 'none'" 是对的，写成 "frame-ancestors "none"" 会导致整个 CSP 失效。
最后提醒一句：如果你的页面需要被自家其他子域 iframe 嵌入（比如 app.example.com 嵌入 widget.example.com），就别用 'none'，改用 frame-ancestors 'self' https://app.example.com，并确保两个域名都配了 HTTPS 和正确证书——HTTP 下的 frame-ancestors 会被浏览器静默降级忽略。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
