应避免直接用 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" 的
• 用 document.body.style.overflow = 'hidden' 锁定背景滚动;
• 用 focus() 主动聚焦到确认按钮,再按 Tab 仍能操作;
• 关闭后手动将焦点移回触发按钮,保持键盘导航连续性。alert() 解决。
前端入门到VUE实战笔记:立即使用
在学习笔记中,你将探索 前端 的入门与实战技巧!











