sandbox="allow-scripts"反而导致跳转失控，因其仅启用脚本执行但默认允许top.location写入，必须显式禁用allow-top-navigation才能阻止子页面劫持父页。
为什么只加 sandbox="allow-scripts" 反而让跳转更危险
子页面里那句 if (top !== self) top.location = self.location 不是 bug，是防嵌套的常规写法。只开 allow-scripts 就等于给它开了“执行 JS”的通行证，但没关掉它写 top.location 的权限——浏览器默认允许脚本修改顶层 location，除非你明确禁止。
Chrome 83+ 和 Firefox 79+ 已把 allow-top-navigation 拆成独立开关：不显式声明，就默认禁用。所以问题不在 JS 拦不住，而在你没提前锁死这个能力。
-
sandbox="allow-scripts"→ 脚本能跑，top.location写操作也成功，父页立刻被劫持 -
sandbox=""或sandbox（空值）→ 脚本直接不执行，页面可能白屏，但跳转风险归零 - 别信“加了 sandbox 就安全”，没配对的
allow-top-navigation才是关键开关
sandbox 怎么配才能彻底封死跳转父页
核心原则：不加 allow-top-navigation，它就不会有权限改 window.top.location；加了就等于授权子页控制整个浏览器窗口。
- 完全禁止跳转父页：
sandbox="allow-scripts allow-same-origin"—— 缺少allow-top-navigation，top.location = xxx静默失败，控制台无报错 - 允许 iframe 内部跳转（比如点击链接在 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"—— 这等于把地址栏交出去
为什么加了 allow-same-origin 还跳转失败或白屏
allow-same-origin 不是信任开关，而是同源校验通过后的解锁钥匙。它只在 iframe 的 src 和父页协议+域名+端口完全一致时才生效；否则浏览器直接忽略该 token，且不提示。
- 父页是
https://a.com，iframe 加载https://b.com/widget.html→allow-same-origin无效，localStorage 仍不可读，fetch()同源请求照样跨域失败 - 生产环境嵌第三方内容（地图、登录页、广告）→ 禁用
allow-same-origin，只按需开allow-scripts或allow-popups - 动态设置
iframe.sandbox = "allow-scripts"无效 —— 属性必须在 DOM 插入前就写死，JS 后续赋值不触发权限重置
调试时怎么确认 sandbox 生效了
别猜，直接查 DOM 属性。打开控制台，运行：
document.querySelector('iframe').sandbox
返回的是 DOMTokenList，比如 DOMTokenList ["allow-scripts", "allow-forms"]，说明配置已生效。如果返回空列表或 undefined，说明属性没正确写进 HTML 或被 JS 覆盖。
注意：子页面跳转后 iframe 显示空白，大概率不是 JS 拦截失败，而是浏览器在加载阶段就因 CSP 或 X-Frame-Options 拒绝渲染 —— 这和 sandbox 无关，得查响应头。
真正容易被忽略的点是：空 sandbox 不是“默认安全”，而是“默认瘫痪”；而 allow-scripts 单独启用时，onclick="xxx" 这类内联事件依然失效——它只解禁 <script></script> 标签和 eval()，不恢复解析阶段的事件绑定。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
