closewatcher api 在移动端不可用，截至2024年中所有主流移动浏览器均未实现，因其设计仅响应esc、dialog.close()等主动关闭行为，不监听系统级返回手势；替代方案需依赖history api或原生桥接。
CloseWatcher API 在移动端是否可用？
目前（截至 2024 年中），CloseWatcher 在所有主流移动端浏览器中均不可用。Chrome for Android、Safari on iOS、Edge Mobile 均未实现该 API；MDN 明确标注其兼容性为「No support」，且无实验性 flag 可启用。你无法在真实移动 WebView 或 PWA 中通过 new CloseWatcher() 监听系统返回手势（如 iOS 底部上滑、Android 返回导航栏）。
为什么 CloseWatcher 不适用于移动端返回手势？
CloseWatcher 的设计目标是响应「主动关闭行为」，比如用户按 Esc、调用 dialog.close()、或点击 <dialog></dialog> 的 backdrop —— 它不监听操作系统级的导航手势，也不挂钩于浏览器历史栈或系统返回键逻辑。移动端的「上滑返回」本质是 WebView 容器或 Safari/Chrome App 自己截获的系统事件，JS 层无权访问。
- iOS：Safari 使用
WKWebView的navigationDelegate拦截，网页 JS 无权限 - Android：系统返回键默认触发
window.history.back()，但上滑手势由 Chrome 自行处理，不派发到 JS -
CloseWatcher的abort事件只在close()被显式调用或 Esc 触发时 dispatch，和手势无关
替代方案：在移动端模拟“返回手势拦截”效果
虽然不能真正监听手势，但可通过组合已有机制，在常见场景下逼近类似体验：
- 对
<dialog></dialog>或模态层：监听popstate+ 手动管理 history 状态，配合history.pushState()占位，使返回键/手势触发时先退到空白状态再关闭模态层 - 对全屏 PWA：使用
beforeinstallprompt后的 standalone 模式，搭配window.onpopstate和history.replaceState()控制返回行为 - 对 WebView 封装应用（如 Capacitor/Cordova）：需原生层桥接 —— iOS 用
WKNavigationDelegate拦截decidePolicyFor，Android 用onBackPressed()重写，再通过 JSBridge 主动通知 JS 层 - 不要依赖
visibilitychange或pagehide：它们在手势过程中不触发，或触发时机滞后，无法用于即时拦截
示例（仅限 history 场景）：
history.pushState({ modal: true }, '', ''); // 打开模态前推一个状态
window.addEventListener('popstate', (e) => {
if (e.state?.modal) {
closeModal(); // 执行你的自定义关闭逻辑
history.replaceState({}, '', location.href); // 清除占位，避免连续触发
}
});
容易被忽略的关键限制
即使未来某天 CloseWatcher 加入移动端支持，它依然不会解决核心问题：系统返回手势在多数情况下不触发页面级事件。iOS 上滑返回直接退出页面，不经过 JS；Android 上滑在 Chrome 中仅用于标签页切换，不作用于当前页。真正可控的只有「返回键」（keydown for Backspace or key: 'Backspace' 在部分安卓浏览器）和「浏览器后退」（popstate）。把希望放在 CloseWatcher 上，等于试图用门把手打开一扇没装门的墙。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
