iframe内跳转会绕过父页控制，因浏览器默认允许子页通过location.href等直接跳转顶层窗口，父页无法拦截且beforeunload不触发；sandbox缺失或误配allow-top-navigation将导致失控，唯一可靠防御是sandbox=""禁用所有导航。
iframe内跳转为什么会绕过父页控制
子页面执行 window.location.href 或 location.replace() 时，只要没加 sandbox 限制，浏览器默认允许它直接跳转整个顶层窗口——这不是 bug，是历史遗留行为。父页 JS 完全无法拦截这个动作，beforeunload 在 iframe 内不触发，popstate 也收不到。
常见错误现象：Blocked a frame with origin "https://child.com" from accessing a cross-origin frame 看似是跨域报错，实际是子页已跳走、父页 DOM 失效后的连锁反应；更隐蔽的是白屏+地址栏突变，控制台却无报错。
- 子页 JS 主动跳转（如 OAuth 回调后
location.href = "/success"）会直接替换top，父页毫无感知 - 第三方脚本（广告、统计 SDK）常内置跳转逻辑，你根本不知道它何时执行
-
target="_blank"在 sandbox 缺失时仍可新开窗口，但若子页用target="_top"，就等于强制接管父页
sandbox="allow-top-navigation" 是危险开关
sandbox 属性里唯一能阻止跳转的其实是「不加」——默认值就是禁用所有导航能力。但很多人误以为要显式开启才安全，结果写成 sandbox="allow-scripts allow-top-navigation"，等于把门钥匙交给子页。
真正起作用的组合只有两种：
立即学习“前端免费学习笔记（深入）”；
-
sandbox=""（空字符串）：彻底禁用所有导航，包括window.location、form.submit()、target="_top"，子页 JS 执行跳转会静默失败（控制台无报错） -
sandbox="allow-scripts"：允许脚本，但禁止任何导航行为；此时子页调用location.href会抛DOMException: Failed to set the 'href' property
注意：allow-top-navigation-by-user-activation 听起来安全，但它只对用户点击触发的跳转放行——而子页完全可以伪造一个 click 事件来绕过。
父页如何检测并补救已发生的跳转
跳转发生后，父页通常只剩空 iframe 和失控的 URL。唯一可行的补救是在跳转前做防御性监听：
- 在 iframe 加载前，用
document.createElement('iframe')动态创建，并立即设置sandbox属性（避免 HTML 中硬编码被覆盖） - 监听 iframe 的
load事件后，立刻检查iframe.contentWindow?.location?.href是否异常变化（仅同源时有效） - 跨域场景下，只能靠
postMessage约定心跳机制：子页每 5 秒发一次{ type: 'alive' }，父页超时未收到就主动 reload iframe
别依赖 window.onblur 或 visibilitychange——它们触发太晚，跳转已完成。
微信网页版等特殊场景的 cookie 陷阱
像微信授权回调页这种同域子页，跳转常由 cookie 触发：子页写入 token → 父页全局登录守卫检测到 → 自动重定向。这不是 iframe 跳转，而是父页自身逻辑被意外激活。
- 子页必须剥离所有状态写入逻辑，只通过
postMessage传递 token 字符串，由父页决定是否存入 cookie - 父页接收消息后，先清空 iframe src（
iframe.src = 'about:blank'），再执行跳转，避免子页残留 JS 继续运行 - 服务端返回的授权页响应头需带
Content-Security-Policy: frame-ancestors 'none'，防止被恶意站点 iframe 套壳复用
真正的防线不在前端 JS，而在子页是否被允许嵌入、是否具备导航权限、以及状态变更是否经过父页仲裁——这三个点漏掉任何一个，跳转就不可控。
