iOS拦截alert、confirm和window.open是因为WKWebView仅允许用户直接同步触发的弹窗，AJAX回调、定时器或postMessage异步调用均被静默拦截；解决方式是通过原生桥接（如messageHandlers）将弹窗交由iOS原生处理。
为什么 iOS 会拦截 alert、confirm 和 window.open
iOS 的 Safari（包括 WKWebView）对弹窗有严格策略：不是由**用户直接、同步触发**的 JS 调用，一律被静默拦截。比如在 AJAX 回调里调 alert、定时器里开 window.open、或通过 postMessage 异步收到指令后再弹窗——全都不行。这不是 bug，是 Apple 明确设计的安全机制。
-
alert/confirm在 WKWebView 中默认不显示，连错误日志都不抛（静默失败） -
window.open('url', '_blank')在非点击事件回调中会被 Safari 直接忽略，且无任何提示 - 即使你关掉系统级“阻止弹出式窗口”设置（
Settings → Safari → Block Pop-ups），WKWebView 内嵌场景仍受原生层更严格的管控
绕过拦截的实操方案：用原生桥接替代 JS 弹窗
最稳定的做法不是“解除拦截”，而是**不让 JS 自己弹**——把弹窗逻辑交还给 iOS 原生层处理。HTML 侧只发通知，原生侧收到后调用 UIAlertController 或自定义模态框。
- 在 WKWebView 配置中注册消息处理器：
webView.configuration.userContentController.add(self, name: "showAlert") - JS 侧改写：
window.webkit.messageHandlers.showAlert.postMessage({title: "提示", message: "操作成功"}); - iOS 原生实现
userContentController(_:didReceive:)，解析 payload 后创建并展示UIAlertController - 同理可扩展
showConfirm、openExternalUrl等能力，避免所有弹窗类 API
临时应急：用 document.createElement("iframe") 欺骗 WKWebView？别试了
网上流传的“iframe 替代 alert”脚本（如动态插入空 iframe 再调 window.frames[0].alert）在 iOS 14+ 已完全失效。WKWebView 对 window.alert 的拦截发生在 JS 引擎层，不是 DOM 层能绕过的。实测结果是：无报错、无弹窗、无日志，代码像没执行一样。
Android Remote Control
下载
远程控制 Android 设备，支持截图、自动化操作手机 App 等功能。本应用使用 uiautomator2 作为底层框架，通过 ADB 连接设备，用户无需 Root（1）查看手机屏幕；（2）自动化操作手机 App；（3）远程安装/卸载应用……
- 该方法仅在部分 Android WebView（如旧版系统内置浏览器）上偶然有效
- 在 iOS 上不仅无效，还会污染
window.frames，可能引发其他 JS 错误 - 如果项目已上线且无法改原生，唯一退路是彻底放弃
alert，改用纯 CSS + JS 实现的 modal 层（需自己控制 z-index、focus、键盘行为等）
补充：Safari 浏览器本身允许弹窗，但必须手动开启
如果你的 H5 页面是直接在 Safari 浏览器中打开（非嵌入 App），那确实可以通过系统设置放行：
立即学习“前端免费学习笔记（深入）”；
- 进入
Settings → Safari → Pop-up Windows，选 “Allow” - 再往下拉到 “Allow Pop-ups for These Websites”，添加你的域名
- ⚠️ 注意：这个设置对 WKWebView 完全无效，它只影响 Safari 浏览器进程本身
- 重启 Safari 才生效，且每次 iOS 升级后可能重置
真正要解决的从来不是“怎么让 iOS 解除拦截”，而是“怎么让业务逻辑不依赖被拦截的 API”。原生桥接不是权宜之计，是混合开发的必经路径。
