sandbox属性是唯一可靠阻止iframe子页面跳转父页的手段，必须显式禁用allow-top-navigation；仅加allow-scripts会放行脚本但默认允许top.location写入，导致劫持风险。
父页面无法直接阻止 iframe 里子页面的 window.top.location 跳转，但能通过 sandbox 属性和 DOM 隔离机制提前封死跳转能力——这是唯一可靠手段，别指望 JS 拦截或重写子页面逻辑。
iframe sandbox="allow-scripts" 为什么反而导致跳转失控
只加 allow-scripts 相当于给子页面开了“执行 JS”的绿灯，但没关掉它篡改顶层 location 的权限。只要子页面含 if (top !== self) top.location = self.location 这类防嵌套代码，父页立刻被劫持跳转。
-
sandbox默认禁用所有危险行为，但显式声明allow-scripts后，脚本可运行，且默认仍允许top.location写入（除非额外限制） - Chrome 83+、Firefox 79+ 已将
allow-top-navigation设为独立开关，不显式声明即禁止子页跳转顶层 - 若子页面是第三方不可控资源（如嵌入地图、登录页），必须去掉
allow-top-navigation，否则等于主动放行跳转
如何用 sandbox 精确阻断子页面跳转父页
核心是关闭 top-navigation 权限，并按需开放其他能力。不要用 * 或模糊配置，否则形同虚设。
- 完全禁止子页跳转父页：
sandbox="allow-scripts allow-same-origin"—— 缺少allow-top-navigation，top.location写操作会静默失败 - 允许子页内跳转（如链接点击）但不跳出 iframe：
sandbox="allow-scripts allow-same-origin allow-forms" - 若需子页弹窗（如扫码登录）：
sandbox="allow-scripts allow-same-origin allow-popups"，但依然不能加allow-top-navigation - 绝对不要写
sandbox="allow-scripts allow-top-navigation"—— 这等于授权子页任意控制你的整个页面
子页面跳转后 iframe 显示空白？检查 CSP 和 X-Frame-Options
不是 JS 拦截失败，而是浏览器在加载阶段就拒绝了 iframe 渲染。常见于子页面返回了 X-Frame-Options: DENY 或父页 CSP 未放行目标域名。
立即学习“前端免费学习笔记（深入）”；
- 打开浏览器 Network 面板，选中 iframe 请求，看 Response Headers 是否含
X-Frame-Options: DENY或Content-Security-Policy: frame-ancestors 'none' - 父页若启用了 CSP，必须在
frame-src中明确列出子页面域名，例如：Content-Security-Policy: frame-src https://example.com - HTTPS 父页加载 HTTP 子页会触发混合内容拦截，控制台报
Mixed Content，此时 iframe 根本不会发起请求 -
sandbox配置错误（如漏掉allow-same-origin却跨域访问）会导致子页 JS 报SecurityError，但跳转本身已被 sandbox 封锁，不会影响父页
为什么 postMessage 不能用于拦截跳转
postMessage 是通信机制，不是防御机制。它只能让子页“通知”父页要跳转，但无法阻止已发生的 top.location 赋值。
- 子页执行
top.location = 'xxx'是同步阻塞操作，JS 执行流瞬间切换上下文，父页来不及响应message事件 - 你监听到的
message通常是子页“跳转前发的告别消息”，此时页面早已开始卸载 - 真正该做的，是在子页加载前就用
sandbox切断跳转通路，而不是等它动手了再喊“停下” - 如果子页是你自己可控的，应在子页 JS 中删掉所有
top.location操作，改用self.location或postMessage告知父页由父页决定是否跳转
最易被忽略的一点：sandbox 属性一旦设置，就不可动态修改；哪怕 JS 修改了 iframe 元素的 sandbox 字符串，浏览器也不会重新评估权限。必须在 iframe 创建时就写对，加载后就彻底锁死。
