## 如何利用 navigator.connection 精准判断网络状态并智能切换图片清晰度 `navigator.connection` API 提供的并非精确的实时带宽数据，而是浏览器基于往返时间（`rtt`）和下行速度（`downlink`）估算出的网络类型（`effectiveType`）。若直接将其作为 Mbps 阈值来切换图片，极易导致误判。要实现真正的弱网适配，必须综合 `downlink` 数值、`saveData` 省流模式以及加载失败兜底策略。 ### 检测 navigator.connection 可用性并读取关键字段 首先需要检查该 API 是否存在，再进行取值操作。需注意，`navigator.connection` 在桌面版 Safari 及部分旧版 Android WebView 中不可用，且 iOS 全系统始终将 `effectiveType` 返回为 `unknown`。 推荐的实际检测代码如下： ```javascript const connection = navigator.connection || navigator.mozConnection || navigator.webkitConnection; if (!connection || !('effectiveType' in connection)) { // 降级方案：使用 navigator.onLine 配合定时测速 return 'unknown'; } // 以下三个字段是核心决策依据 const effectiveType = connection.effectiveType; // 可能值：'4g', '3g', '2g', 'slow-2g' const downlink = connection.downlink; // 单位 Mbps，在某些浏览器中可能为 undefined const saveData = connection.saveData; // 布尔值，指示用户是否开启了数据节省模式 ``` 重要提示：`downlink` 字段在 Chrome 100+ 版本中才稳定返回，Firefox 中常为 `undefined`；一旦 `saveData` 为 `true`，应无条件切换至最低清晰度资源，此优先级高于 `effectiveType`。 ### 基于 effectiveType 与 downlink 组合制定图片清晰度策略 仅依赖 `effectiveType` 容易出错：例如，网络类型显示为 `'4g'`，但实际 `downlink` 仅为 0.8 Mbps（可能处于拥堵的 Wi-Fi 环境）；或类型为 `'3g'`，但 `downlink` 高达 12 Mbps（实为高速 5G 覆盖区）。因此必须进行交叉验证。 * **若 `saveData === true`** → 强制使用 `320w.webp?q=30` 格式图片，忽略其他所有字段。 * **若 `effectiveType === 'slow-2g'` 或 `effectiveType === '2g'`** → 使用 `320w.webp?q=40`，并考虑禁用懒加载以确保核心内容优先呈现。 * **若 `effectiveType === '3g'` 且 `downlink < 2`** → 使用 `750w.webp?q=50`。 * **若 `effectiveType === '3g'` 且 `downlink >= 2`，或 `effectiveType === '4g'`** → 可使用更高清晰度，如 `1080w.webp?q=70`。 * **若 `effectiveType === 'unknown'` 或 `downlink` 未定义** → 回退至通用兼容格式，如 `750w.jpg`。 ### 谨慎处理 change 事件并建立轮询机制 `connection.addEventListener('change')` 事件的触发存在延迟，且不保证覆盖所有网络波动。实测表明，从 4G 切换至 3G 可能延迟 8-12 秒，在高丢包率场景下甚至可能完全不触发。 更稳妥的实现方案包括： * **首次加载**：依据当前的 `connection` 属性值进行决策。 * **启动轮询**：使用 `setInterval(() => { /* 重新读取 downlink / effectiveType */ }, 5000)`，每 5 秒主动检测一次网络状态。 * **结果防抖**：连续 2 次检测到 `downlink < 1.5` Mbps，才判定为进入弱网状态，避免因瞬时波动导致频繁切换。 * **渐进切换**：不实时替换已渲染图片的 `src`，仅将新的网络策略应用于后续新插入的 `` 元素。 ### 必须结合 onerror 与超时控制实现最终保障 Network Information API 提供的是估算值，实际网络链路可能因 DNS 解析、CDN 节点、服务器拥塞等因素而远差于预期。当一张图片加载超过 3 秒未响应，或触发 `onerror` 事件时，应立即启动降级流程。 示例代码片段如下： ```javascript function loadImgWithFallback(img, src) { const controller = new AbortController(); const timeoutId = setTimeout(() => controller.abort(), 3000); fetch(src, { signal: controller.signal }) .then(res => { if (res.ok) { img.src = src; } else { throw new Error(`HTTP ${res.status}`); } }) .catch(() => { const fallbackSrc = getLowQualitySrc(src); // 例如转换为 ?q=30&w=320 格式 if (!img.dataset.attemptedFallback) { img.dataset.attemptedFallback = '1'; loadImgWithFallback(img, fallbackSrc); } else { img.src = '/placeholder.svg'; // 避免无限重试循环 } }) .finally(() => clearTimeout(timeoutId)); } ``` 核心要点： * **单次降级原则**：同一张图片最多执行一次降级重试，防止陷入“质量越降越低、失败后继续降级”的恶性循环。 * **精准请求控制**：使用 `AbortController` 与 `fetch` API 搭配，而非仅依赖 `` 标签的 `onload`/`onerror` 事件，因为后者无法有效中止卡在 DNS 查询或 TLS 握手阶段的请求。 尤其需要注意的是：**iOS Safari 完全不支持 `connection.change` 事件，且 `effectiveType` 恒为 `unknown`**。因此，上述的轮询机制、结合 `downlink` 判断以及 `onerror` 兜底的组合策略，在 iOS 平台上反而成为了核心的网络适配方案。