应避免直接用 navigator.onLine 触发 alert()，而需通过 fetch 心跳 + AbortController 主动探测服务端健康状态，并仅在用户有操作意图（如点击提交按钮或连续两次心跳失败）时，使用可访问、可聚焦的自定义弹层提示。
直接用 navigator.onLine 触发 alert() 是错的
很多代码一看到 offline 事件就立刻 alert("网络已断开")，但这样既不准也不及时。原因有三：
• navigator.onLine 在 DNS 失败、后端挂掉、代理拦截时仍返回 true，用户点提交按钮照样失败；
• 飞行模式刚开启时，offline 事件可能延迟 2–5 秒才触发，期间用户已完成多次点击；
• alert() 是同步阻塞的，弹出瞬间会卡住页面 JS 执行，心跳检测、重试逻辑全被挂起。
必须用 fetch 心跳 + AbortController 判断真实连通性
真正要警告的不是“有没有网”，而是“你的 API 还能不能响应”。所以得主动探测服务端健康状态：
• 心跳 URL 必须是业务同源路径（如 /api/health），不能是 https://google.com 这类跨域地址；
• 每次请求必须带 AbortController 控制超时（建议 3000ms），避免请求长期 pending 占用连接；
• 后端该接口必须真实检查 DB 连通、缓存可用、依赖服务就绪，不能只返回静态 { "status": "ok" }；
• 心跳间隔设为 ≥15 秒——太密会触发 CORS 预检失败、服务限流或移动端耗电激增。
什么时候该弹警告框？只在心跳失败且用户有操作意图时
盲目每 15 秒弹一次 alert() 会把用户逼疯。合理时机只有两个：
• 用户点击了关键操作按钮（如提交表单），但当前最近一次心跳失败（即 fetch 被 reject 或响应非 200）；
• 页面处于前台、用户正在输入，且连续两次心跳失败（比如 30 秒内都不可达），此时可弹一次温和提示（用自定义弹层，非 alert）；
• 禁止监听 online/offline 事件后立刻 alert()——网络抖动时会疯狂弹窗，且 online 触发不等于服务已恢复。
弹窗本身不能用 alert()，得用可中断、可样式化、可聚焦管理的 DOM 弹层
alert() 的阻塞性和不可定制性，在现代页面中已成反模式：
• 它无法阻止用户继续滚动、切换 Tab、甚至刷新页面；
• 无 CSS 控制，与品牌色、字体、无障碍要求完全脱节；
• 屏幕阅读器无法识别其语义，aria-live 和焦点捕获全部失效。
推荐做法：用一个带 role="alertdialog" 的 <div>，显示时：<br>• 用 <code>document.body.style.overflow = 'hidden' 锁定背景滚动；
• 用 focus() 主动聚焦到确认按钮，再按 Tab 仍能操作；
• 关闭后手动将焦点移回触发按钮，保持键盘导航连续性。
立即学习“前端免费学习笔记（深入）”；
真实场景里最容易被忽略的点是：**心跳失败 ≠ 立刻弹窗，而弹窗 ≠ 必须打断用户**。是否提示、提示多强、是否允许绕过，取决于操作风险等级和用户当前上下文——这些没法靠一个alert() 解决。
