最简且跨域安全的 iframe 检测方式是 window.self !== window.top：前者为 true 表明在 iframe 中，后者跨域时抛 securityerror 亦可判定；需置于 head 顶部立即执行，禁用 window.frameelement 因其跨域返回 null 且兼容性差；跳转必须用 window.top.location = window.location 避免被拦截。
用 window.self !== window.top 做最简判断
这是唯一能穿透任意深度嵌套、且跨域安全的检测方式。只要当前页面不是顶层窗口，window.self !== window.top 就为 true；跨域 iframe 中访问 window.top 会抛出 SecurityError，这个异常本身也说明它在 iframe 里。
常见错误是只比 window.parent !== window —— 这漏掉多层嵌套（比如 A 嵌 B，B 嵌 C，C 页面只看 parent 就以为自己是顶层）；更糟的是等 DOMContentLoaded 后再执行，此时攻击者可能已注入透明覆盖层。
正确姿势是：把检测代码放在 最顶部、任何第三方脚本之前，一加载就跑：
<script>
if (window.self !== window.top) {
window.top.location = window.location;
}
</script>
为什么不用 window.frameElement
window.frameElement 确实简洁，但它在跨域 iframe 中返回 null（不是报错），导致误判为“不在 iframe 中”。而实际场景中，恶意嵌入几乎全是跨域的，这时候它就完全失效。
另外，IE8–IE10 不支持该属性；某些 WebView（如旧版安卓系统）也会返回 undefined。如果你的项目要兼容这些环境，或安全要求高，就不能依赖它。
它适合的场景仅限于：同源 iframe 内部调试、内部管理后台子页面识别父容器，且明确知道不会被跨域嵌入。
检测后跳转时要注意 window.top.location 的写法
别用 window.top.location.href = ... 或 window.top.location.replace(...)，部分浏览器（尤其是 Safari 和 iOS WKWebView）对跨域 top.location 赋值有拦截逻辑，可能静默失败。
必须用 window.top.location = window.location 这种直接赋值方式，它触发的是 location 对象替换，绕过部分限制。
如果页面需被自家子域名合法嵌入（如 app.example.com 嵌入 widget.example.com），这个跳转逻辑必须由服务端控制开关——前端硬编码会破坏正常业务流程。
复杂点在于“需要嵌入但又要防劫持”的混合策略
很多 SaaS 工具页既要支持客户嵌入（如仪表盘 widget），又要防止被钓鱼站 iframe 套壳。这时候不能一刀切跳转，得结合 document.referrer + frameElement?.src + CSP 的 frame-ancestors 响应头做多层校验。
但注意：document.referrer 可被伪造，不能单独信任；frameElement.src 在跨域下读不到；真正可靠的只有服务端下发的白名单 + 前端 origin 校验 postMessage 通信链路。
这种场景下，前端检测只是第一道网关，后续所有敏感操作都得走带签名的跨域消息通道，而不是靠一次性的“是否在 iframe”布尔值做决策。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
