iOS中navigator.onLine不准因采用乐观策略，仅检测网络接口状态而非真实可达性；应改用fetch+AbortController超时探测后端健康接口来准确判断。
HTML5 navigator.onLine 在 iOS 上为什么经常不准
因为 iOS WebView（包括 Safari 和 WKWebView）对 navigator.onLine 的实现是「乐观策略」：只要系统认为有任意网络接口（比如 Wi-Fi 已连接但未获取到 IP、或蜂窝已开启但信号极弱），就返回 true；它不检测真实可达性，也不发起任何网络探测。你看到的「已联网」可能只是设备连上了空转的热点，或刚断开 2 秒还没来得及触发 offline 事件。
iOS 中真正可用的网络检测方式：用 fetch + 超时兜底
必须主动发一个轻量请求（如 GET /favicon.ico 或一个无缓存的 /health 端点），靠响应状态和超时判断是否真能通外网。关键不是「有没有网卡」，而是「能不能拿到响应」。
实操建议：
- 不要依赖
navigator.onLine做核心逻辑，只用它做快速初筛（比如跳过明显离线时的 fetch） - 发起 fetch 时务必设置
signal+AbortController控制超时，iOS 上默认超时极长（有时 >30s），用户会以为卡死 - 目标 URL 应该是自己可控的后端健康检查接口（避免跨域或 CDN 缓存干扰），且返回 HTTP 200 + 空 body
- 避免用图片或
XMLHttpRequest，iOS 对其错误回调不一致，fetch更可靠
示例片段：
立即学习“前端免费学习笔记（深入）”；
const controller = new AbortController();
setTimeout(() => controller.abort(), 3000);
<p>try {
const res = await fetch('/api/health', { signal: controller });
return res.ok; // true 表示网络可用
} catch (e) {
return false; // 包括网络拒绝、超时、DNS 失败等
}WKWebView 里还要注意 native 层的干扰
iOS 的 WKWebView 默认启用 allowsInlineMediaPlayback 等优化，但某些企业级 MDM 或旧版 iOS（如 15.4 之前）会静默禁用后台网络请求，导致 fetch 在页面切到后台后立即失败——这不是 JS 问题，是 WebKit 策略。
解决路径：
- 在
WKWebViewConfiguration中显式设置processPool为新实例（避免复用被污染的进程） - 确保
webView.navigationDelegate没有拦截didFailNavigation并吞掉错误 - 若需后台保活检测，必须配合原生定时器（
NSTimer）+evaluateJavaScript注入，纯 JS 的setInterval在后台会被系统大幅降频甚至暂停
别忽略 DNS 和 TLS 握手失败这种「半联通」场景
用户常遇到「能打开微信但打不开你的网页」，本质是 DNS 解析失败或证书校验不通过——fetch 会直接抛 TypeError，但不会告诉你具体是哪一环挂了。iOS 对自签名证书、过期证书、SNI 不匹配的容忍度比桌面端更低。
调试建议：
- 用
curl -v https://your-domain.com/api/health在 Mac 上复现，观察是卡在* Connected to...还是* SSL connection - 如果仅在 iOS 出问题，大概率是证书链不全（缺 intermediate CA），用
openssl s_client -connect your-domain.com:443 -showcerts验证 - 前端可加一层简易 DNS 可达性提示：先 fetch 一个已知稳定的第三方地址（如
https://dns.google/resolve?name=your-domain.com），再 fetch 自己的接口
真正的网络状态从来不是布尔值，而是一组带上下文的可观测指标：DNS 耗时、TLS 握手耗时、首字节时间、HTTP 状态码分布。iOS 上尤其不能省掉这层验证。
