本文介绍在本地文件（file://）或网页环境中检测用户是否具备有效互联网连接的多种可靠方法，涵盖 navigator.online 的局限性、主动探测策略及实际代码示例。
本文介绍在本地文件（file://）或网页环境中检测用户是否具备有效互联网连接的多种可靠方法，涵盖 navigator.online 的局限性、主动探测策略及实际代码示例。
在 Web 开发中，仅凭 document.location.protocol === 'file:' 并不能判断用户是否联网——它只说明页面是从本地加载的，而页面功能（如调用 API、加载远程资源、同步数据）仍可能严重依赖活跃的互联网连接。因此，需采用更健壮的检测机制。
1. navigator.onLine：快速但不可靠的初步判断
navigator.onLine 返回布尔值，表示浏览器认为网络“在线”（如网卡启用、未处于飞行模式），但它无法确认真实可达性：
- 在离线状态下禁用 Wi-Fi 后可能仍返回 true（尤其在桌面浏览器中）；
- 切换到无出口的局域网（如仅连接路由器但无外网）时也常误报为 true；
- Chrome 和 Firefox 对其行为定义略有差异，且不触发跨域限制。
if (navigator.onLine) {
console.log("浏览器认为在线 —— 但未必能访问互联网");
} else {
console.log("明确离线（如断网或飞行模式）");
}✅ 适合用于 UI 快速响应（如显示“离线模式”提示）；
❌ 不可用于决定关键网络操作（如发起 API 请求前的守卫逻辑）。
2. 主动网络探测：推荐的可靠方案
真正验证互联网连通性，应向一个高可用、低延迟、无 CORS 阻碍的公共端点发起轻量级请求。推荐使用：
- https://www.google.com/generate_204（Google 的 204 端点，返回空响应，极快且稳定）；
- 或 https://httpstat.us/200（HTTP 状态服务）；
- 自建健康检查端点（如 /api/health）更可控，但需部署支持。
以下是一个可复用的探测函数，带超时与错误处理：
立即学习“Java免费学习笔记（深入）”；
async function isInternetConnected(timeout = 5000) {
const controller = new AbortController();
const id = setTimeout(() => controller.abort(), timeout);
try {
const response = await fetch('https://www.google.com/generate_204', {
method: 'HEAD',
cache: 'no-cache',
signal: controller.signal
});
clearTimeout(id);
return response.status === 204; // 仅当返回 204 才确认连通
} catch (err) {
clearTimeout(id);
return false;
}
}
// 使用示例
isInternetConnected().then(connected => {
if (connected) {
console.log("✅ 已确认互联网连接正常");
} else {
console.log("❌ 无法访问互联网，请检查网络");
}
});⚠️ 注意事项：
- 避免频繁调用（建议节流，如每 30 秒最多一次）；
- 生产环境请避免依赖第三方服务（如 Google），优先使用自有健康端点；
- 若页面运行于 file:// 协议下，fetch 默认受 CORS 限制——但 generate_204 支持跨域，且 HEAD 方法兼容性良好；
- 移动端需注意蜂窝网络切换延迟，建议结合 navigator.onLine 做初始过滤再发起探测。
总结
检测“真实互联网连接”不能依赖单一指标：
? document.location.protocol 仅标识加载来源，与网络状态无关；
? navigator.onLine 是轻量级启发式信号，适合 UI 反馈，但不可信；
? 主动 HTTP 探测（如 HEAD 请求 204 端点）是当前最实用、兼容性最佳的验证方式。
将二者结合（先查 onLine，再按需探测），即可在本地文件场景下稳健支撑依赖网络的核心功能。
