用 fetch 检查 api 在线状态应优先发 head 请求，失败则降级 get；需捕获 typeerror 处理网络层错误（如 dns 失败、cors），配合 signal 设置超时，并区分 response.status 为 0（网络失败）与 503 等 http 状态；避免依赖 navigator.online 或 visibilitystate，健康检查应独立定时运行，状态切换通过 class 控制显隐防重排。
怎么用 fetch 检查 API 是否在线，而不是靠肉眼刷新页面
直接发个 HEAD 或 GET 请求看响应状态码，比写死“Loading…”靠谱得多。HEAD 更轻量，但有些服务不支持或返回 405；GET 更通用，但得注意别触发副作用（比如重复提交）。实际用时优先试 HEAD，失败再降级到 GET。
常见错误现象：fetch 报 TypeError: Failed to fetch —— 这通常不是后端挂了，而是网络中断、CORS 被拦、或目标域名根本没响应（DNS 失败、服务未监听）。这时候 response.status 根本不会出现，必须在 catch 里处理。
- 加
signal配置超时，避免请求卡死（默认无超时） - 不要只判断
response.ok === true，要区分503 Service Unavailable和0状态（后者代表网络层失败） - 如果后端是 Express/Koa，确保健康检查路由（如
/health）不走鉴权中间件，否则未登录时会误报“离线”
HTML 里显示“在线/离线”文本，但别让 DOM 重排闪一下
状态变化频繁时，直接 innerHTML 替换会导致浏览器重排，尤其在低配设备上肉眼可见闪烁。更稳的方式是预先写好两套文案，用 class 控制显隐，只切 class 不动结构。
使用场景：顶部状态栏、仪表盘右上角小徽章、表单提交前的依赖服务提示。
- HTML 中写：
<span class="status-indicator"><span class="status-text--up">✅ 在线</span><span class="status-text--down">⚠️ 离线</span></span> - JS 只操作 class：
el.classList.toggle('is-down', isOffline)，配合 CSS 的.status-text--up:not(.is-down) { display: inline; } - 避免用
visibility: hidden隐藏备用文案——它仍占布局空间，可能影响对齐
为什么 document.visibilityState 不能代替 API 健康检查
页面切到后台时 visibilityState 变成 hidden，但此时 API 完全可能正常；反之，页面在前台时，API 也可能因部署、网络抖动瞬间不可达。两者维度不同：一个是浏览器标签页生命周期，一个是服务端可用性。
容易踩的坑：有人把定时轮询逻辑绑在 visibilitychange 上，以为“页面切回来就立刻检查”，结果用户切回时发现状态滞后 30 秒——因为上次检查还在 pending，新检查被节流掉了。
- 健康检查应独立运行，和 visibility 无关；但可利用它暂停轮询（节省资源）
- 恢复可见时，别立即重试，先等 1–2 秒再发请求，避开系统唤醒抖动期
-
document.hasFocus()也不可靠：iframe 里的页面可能有焦点但被遮挡，或全屏视频下页面失去焦点但 API 仍需工作
用 Navigator.onLine 判断网络通不通？小心它只是个“网线插没插”指示器
Navigator.onLine 返回 true 只表示浏览器认为网络“可用”，比如 Wi-Fi 已连但路由器没拨号、或公司内网 DNS 故障——它照样返回 true。反过来，它返回 false 倒是相对可信（真断网了），但覆盖场景太窄。
性能影响：这个属性读取极快，但信息价值极低。拿它当 API 健康代理，等于用温度计测血压。
- 不要用它替代真实的 HTTP 探测
- 可以作为快速短路条件：若
navigator.onLine === false，直接标“离线”，省一次 fetch - 注意 Safari 在某些版本中，
onLine在 iframe 里可能始终返回true
真正难的不是发请求或改文字，是定义“什么算健康”：是能连上 TCP？HTTP 返回 2xx？还是数据库查询也得跑通？这个边界一旦模糊，前端状态就会在“看起来正常”和“点一下就报错”之间反复横跳。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
