默认sandbox即全锁死而非仅拦截弹窗，必须显式配置sandbox="allow-scripts allow-popups"才支持用户手势触发的弹窗，禁用allow-same-origin和allow-top-navigation以保障安全。
iframe sandbox 默认就拦截弹窗，但必须显式配置
只写 sandbox 或 sandbox="" 时，弹窗（window.open()、alert()、confirm()）全被静默拦截，连控制台都不报错。但这会导致 iframe 白屏——脚本不执行、图片不加载、DOM 不解析，根本不是“只拦弹窗”，而是“全锁死”。真正可用的起点是至少加 allow-scripts。
-
sandbox="allow-scripts"：脚本能运行，但所有弹窗仍被拦截（window.open()返回null，alert静默丢弃） -
sandbox="allow-scripts allow-popups"：仅允许用户手势触发的弹窗（如点击后调用window.open()），自动弹窗（如页面 onload 时触发）仍失败 -
sandbox="allow-scripts allow-popups allow-popups-to-escape-sandbox"：极少数场景需要（如嵌入支付回调页），但会绕过沙箱限制，风险陡增，不推荐
为什么加了 allow-scripts 还有弹窗？检查是否误配 allow-popups
常见错误是以为“开了脚本就能弹”，结果广告或统计 SDK 自动调用 window.open()，却没配 allow-popups。此时 Chrome/Firefox 中该调用静默返回 null，控制台无提示；Safari 可能抛 DOMException: Blocked a frame from opening a popup。
- 第三方广告 iframe 必须配
allow-popups才能响应点击跳转，否则按钮点击无反应 - 若弹窗用于 OAuth 回调或扫码登录，需确认触发时机是否满足“用户手势”（click/touch），否则即使配了
allow-popups也会失败 - 不要加
allow-top-navigation来“辅助弹窗”——它和弹窗无关，只管顶层跳转，且极度危险
父页面无法靠 JS 拦截子页面弹窗，别试 window.open 重写
有人试图在父页注入代码覆盖 window.open，或监听 beforeinstallprompt，这些完全无效：beforeinstallprompt 是 PWA 安装事件，和弹窗无关；而子页面的 window.open 在自身上下文中执行，父页重写自己的 window.open 对它毫无影响。
- 唯一可控手段是 sandbox 属性——它在 iframe 加载前就由浏览器内核级拦截
- 动态设置
iframe.sandbox = "allow-scripts"无效，必须写在 HTML 标签里：<iframe sandbox="allow-scripts allow-popups"></iframe> - 服务端若返回
X-Frame-Options: DENY或 CSPframe-ancestors 'none'，iframe 根本不会加载，更别说弹窗了
移动端弹窗行为更严格，allow-popups 不等于“全放开”
Android Chrome 和 iOS Safari 对弹窗管控更强：即使配了 allow-popups，若子页面没有明确的用户手势上下文（比如 setTimeout 延迟触发），window.open() 仍会失败。这不是 bug，是浏览器主动降权。
- 测试时务必真机点击，不能靠 DevTools 的 “Emulate touch” 代替
- 避免在
iframe的load事件里自动弹窗，改用显式按钮 + click 事件绑定 - 部分广告 SDK 会用
document.write注入弹窗逻辑，而sandbox下document.write被禁用，这类广告直接失效——这反而是好事
allow-popups 一旦加上，就必须接受它带来的用户交互边界；漏掉它，弹窗就彻底消失；加错配套项（比如混入 allow-same-origin），可能让广告脚本读取父页 cookie。真实环境里，多数第三方广告只需 allow-scripts allow-popups 就够用，多一个字都可能是漏洞入口。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
