sandbox中仅allow-popups无效，必须同时设置allow-scripts和allow-popups；弹窗是否成功取决于用户手势，而非sandbox配置。
allow-popups 在 Chrome 和 Firefox 中默认行为一致，但弹窗实际能否打开取决于是否配对 allow-scripts
单独写 sandbox="allow-popups" 在两个浏览器里都不会让 window.open() 生效——因为规范要求：弹窗能力必须与脚本执行能力共存。Chrome 和 Firefox 都严格遵循这点，不给例外。
常见错误现象是开发者只加了 allow-popups，结果调用 window.open() 返回 null，控制台也无报错，容易误判为“没触发”。
实操建议：
- 必须同时声明
allow-scripts和allow-popups，例如：sandbox="allow-scripts allow-popups" - 如果 iframe 内还要操作
opener或跨窗口通信，还需补上allow-same-origin（但会削弱隔离性） - Firefox 123+ 和 Chrome 122+ 对该组合的行为完全一致，无需条件判断
allow-popups-to-escape-sandbox 在 Safari 上基本无效，Chrome/Firefox 也有限制
这个值的本意是让弹出的新窗口“脱离沙箱”，获得完整权限。但现实中，Chrome 和 Firefox 实际上只解除新窗口自身的 sandbox 属性，而不会赋予它访问父页面 DOM 或 Cookie 的能力；Safari（iOS 15–16）则直接忽略该 flag，新窗口仍被沙箱限制。
使用场景很窄：仅适用于你明确需要新窗口加载不受限的第三方页面（比如跳转到支付网关），且不依赖与父页交互。
实操建议：
- 不要依赖
allow-popups-to-escape-sandbox实现父子通信或状态同步 - 若需传参，改用
postMessage()+allow-scripts组合更可靠 - 在 Safari 中测试时，应默认当作未启用该 flag 处理
弹窗被拦截的真正原因往往不是 sandbox，而是用户手势缺失
即使 sandbox 配置正确，window.open() 仍可能返回 null，这是浏览器主动拦截，和 sandbox 无关。触发条件是：调用不在用户手势（如 click、keydown）事件处理函数内。
典型错误：
- 在
setTimeout(() => window.open(...), 100)中调用 - 在
fetch().then(() => window.open(...))中调用 - 在
iframe加载完成回调（load事件）中调用
实操建议：
- 确保
window.open()直接位于用户事件处理器顶层，不要嵌套异步链 - 如需异步准备数据，先缓存，再在点击事件中立即调用
window.open() - Chrome 控制台会输出
Failed to open window: Blocked by browser policy，Firefox 类似提示为Window.open() was blocked
移动端 Safari 的 sandbox 弹窗限制最严，且不报错
iOS 15–16 的 Safari 对 sandbox iframe 内的弹窗做了额外封锁：即使配置了 allow-scripts allow-popups，window.open() 也会静默失败（返回 null），且控制台不打印任何提示。这是 Apple 的主动策略，不是 bug。
这不是兼容性问题，而是平台级限制。目前没有绕过方式。
实操建议：
- 在 iOS Safari 上，避免依赖 sandbox iframe 内主动弹窗；改用
location.href跳转或<a target="_blank"></a>链接 - 检测环境时可用
navigator.userAgent.includes('iPhone') || navigator.userAgent.includes('iPad') - 不要在 sandbox iframe 中尝试捕获
window.open()的异常——它根本不会抛错
