根据网络带宽加载不同清晰度图片的实现方法

本文深入解析了如何利用 `navigator.connection` API 实现基于真实网络状况的图片自适应加载，强调其返回的是启发式估算值而非精确带宽，尤其指出 iOS 全系 `effectiveType` 恒为 `unknown` 的兼容痛点；文章不仅提供按 `downlink` 数值、`effectiveType` 类型和 `saveData` 开关三者交叉判断的精细化清晰度策略，更强调必须结合轮询检测、防抖处理、`onerror` 与 `AbortController` 超时降级（单次降级防死循环）、以及兜底 fallback 等多重保障机制，才能在弱网、高丢包、DNS 卡顿等复杂真实场景下稳定提升首屏性能与用户体验。

navigator.connection 能拿到的不是“精确带宽”，而是浏览器基于 rtt 和 downlink 估算出的启发式网络等级（effectiveType），直接拿它当 Mbps 切图会误判。必须结合 downlink 数值、saveData 开关和加载失败兜底，才能真正适配弱网。

判断 navigator.connection 是否可用并读取基础字段

先检查 API 是否存在，再取值——navigator.connection 在 Safari 桌面版、部分旧 Android WebView 中不可用，且 effectiveType 在 iOS 全系始终返回 unknown。

实际检测逻辑要写成：

const connection = navigator.connection ||
  navigator.mozConnection ||
  navigator.webkitConnection;
if (!connection || !('effectiveType' in connection)) {
// 降级为 navigator.onLine + 定时 fetch 测速
return 'unknown';
}
// 这三个字段才是关键决策依据
const effectiveType = connection.effectiveType; // '4g', '3g', '2g', 'slow-2g'
const downlink = connection.downlink;           // number, 单位 Mbps，可能为 undefined
const saveData = connection.saveData;          // boolean，用户是否开了省流模式

注意：downlink 在 Chrome 100+ 才稳定返回，Firefox 仍常为 undefined；saveData 一旦为 true，应无条件切最低清资源，比 effectiveType 优先级更高。

按 effectiveType + downlink 组合决定图片清晰度策略

只看 effectiveType 容易翻车：比如 effectiveType === '4g' 但 downlink === 0.8（实为拥堵 Wi-Fi），或 effectiveType === '3g' 但 downlink === 12（高速 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 才认为进入弱网，避免抖动误判
• 不做实时切换已渲染图片，只影响后续新 的 src 设置

必须搭配 onerror 和超时控制做最终兜底

Network API 是估算，真实链路可能因 DNS、CDN、服务器拥塞而远差于预期。一张图加载超过 3 秒没响应，或触发 onerror，就得立刻降级。

示例逻辑片段：

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));
}

重点：单张图最多降级 1 次，否则容易陷入“越切越糊→越失败→再切”的死循环；AbortController 要配 fetch，不能只靠 的 onload/onerror——后者无法感知卡在 DNS 或 TLS 握手阶段的请求。

最易被忽略的是：iOS Safari 完全不支持 connection.change 事件，且 effectiveType 永远是 unknown，所以轮询 + downlink + onerror 这套组合拳，在 iOS 上反而是主力判断方式。

本篇关于《根据网络带宽加载不同清晰度图片的实现方法》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！