navigator.connection.rtt在多数浏览器中不可用，chrome 124+仅有限支持，safari/firefox不实现，读取返回undefined；应优先使用effectivetype与downlink组合判断网络状态。
navigator.connection.rtt 本身并不存在 —— 浏览器没有这个属性，直接读取会返回 undefined，所有依赖它的动态加载逻辑都会静默失效。
为什么 navigator.connection.rtt 是无效的
Web 标准中 navigator.connection（Network Information API）只暴露 effectiveType、downlink、rtt 等字段，但 rtt 字段在 Chrome 124+ 才开始有限支持，且仅限 HTTPS + 安全上下文 + 用户手势触发后的页面，并非稳定可用。更关键的是：当前绝大多数浏览器（包括 Safari 全系、Firefox、旧版 Chrome）根本不实现 rtt 属性，读取即 undefined。
- Chrome 123 及更早版本：
navigator.connection.rtt永远是undefined - Safari 和 Firefox：
rtt属性根本不在NavigatorNetwork接口中 - 即使 Chrome 返回了数值，单位是毫秒，但它是估算值，波动大（比如同一页面两次读取差 200ms），不适合做精细优先级切换
真正可用的网络信号：用 effectiveType 和 downlink 组合判断
这两个字段兼容性好（Chrome 61+、Edge 79+，Firefox 90+ 也已支持 downlink），且语义明确：effectiveType 表示“有效连接类型”（'slow-2g' / '2g' / '3g' / '4g'），downlink 是估算下行带宽（MB/s 单位，如 1.5 表示 ≈12 Mbps）。
- 优先用
effectiveType做粗粒度分档（如'2g'强制跳过高清图） - 当
effectiveType === '4g'时，再用downlink > 10判断是否可加载 4K 视频片段 - 监听
navigator.connection.onchange，但注意该事件不保证实时 —— 实际延迟可能达数秒，适合降级策略，不适合帧级响应
在 React/Vue 单页应用中落地高清素材分级加载
不要全局监听一次就缓存结果；每次图片/视频组件挂载时，应重新评估当前网络状态，并结合资源尺寸决策。
- 对
<img>：用srcSet+sizes配合media查询，但需补充 JS 回退逻辑 —— 比如检测到effectiveType === '2g'，就强制将src指向/img/logo-100w.jpg而非默认的2x版本 - 对懒加载资源：在
IntersectionObserver回调中读取navigator.connection.effectiveType，若为'slow-2g'，则跳过fetch()，直接渲染占位灰图 - 避免在 SSR 或服务端预判 ——
navigator对象仅存在于客户端，服务端访问会报错或返回空对象
容易被忽略的边界情况
用户开着 WiFi 但路由器连着 4G 热点，effectiveType 可能返回 '3g'；公司内网走代理后，downlink 可能虚高。这些都不是 bug，而是 Network API 的设计使然。
-
navigator.connection不反映瞬时拥塞，只反映「近期平均链路能力」，别拿它做防抖节流的依据 - iOS Safari 对
downlink返回值始终为1.0（无论真实带宽），不能单独依赖 - 如果用户禁用了「限制数据用量」，部分 Android WebView 可能不提供
connection数据，需准备兜底策略（如 localStorage 记录上次成功加载的分辨率）
真正在意高清素材加载时机，得接受网络指标是模糊信号 —— 它只能帮你避开明显不可行的路径，而不是精确控制每一帧。把 rtt 当成可用字段，大概率会让首屏高清图在弱网下彻底白屏，而且你还不知道为什么。
