可直接用 navigator.connection.rtt 动态调节静态资源并发加载数：rtt≤50ms设6～8，并发；50ms＜rtt≤150ms设3～4；rtt＞150ms压至1～2，并以effectivetype兜底校验。
可以直接用 navigator.connection.rtt 作为核心依据，结合网络响应质量分级，动态设置高清图等静态资源的并行加载数。RTT（往返延迟）比带宽更稳定、更易获取，且对用户感知明显——高 RTT 时强行并发会加剧排队和超时，低 RTT 时则可安全提升并发加速就绪。
按 rtt 数值划分并发策略区间
RTT 是毫秒级延迟指标，反映链路响应及时性。不建议直接映射为固定数值，而应分段设定合理并发范围：
- rtt ≤ 50ms：优质网络（如千兆 Wi-Fi、有线、强信号 5G）→ 并发数设为 6～8，充分利用空闲 TCP 连接槽位
- 50ms ：中等网络（普通 4G、弱 Wi-Fi）→ 并发数设为 3～4，兼顾加载速度与连接稳定性
- rtt > 150ms：弱网或高抖动环境（2G/3G、偏远蜂窝、卫星链路）→ 并发数压至 1～2，避免请求堆积和大量 timeout
注意：需用 navigator.connection.effectiveType 做兜底校验。例如 rtt=120ms 但 effectiveType === 'slow-2g'，仍应强制走 1～2 并发策略。
在资源加载器中集成 rtt 感知逻辑
不要在每个 fetch 或 Image 创建时临时判断，而是封装一个统一的并发控制器，供图片预加载、懒加载、批量缩略图渲染等场景复用：
- 初始化时读取
connection.rtt，设默认并发值；若不可用（如 Safari 不支持），回退到固定值（如 4）或基于effectiveType推断 - 监听
connection.change事件，在网络状态变化时重新计算并发数（注意兼容性：部分浏览器不触发该事件，可辅以定时轮询） - 将高清图加载任务接入请求池（request pool），由控制器按当前并发上限调度执行，而非直接发起
配合 CDN 与 HTTP/2+ 进一步释放并发收益
RTT 驱动的并发调节效果，高度依赖底层传输效率。若未启用现代协议或边缘加速，调高并发可能收效甚微甚至适得其反：
- 确保静态资源（尤其是高清图）托管在支持 HTTP/2 或 HTTP/3 的 CDN 上，利用多路复用减少连接竞争
- 服务端开启
Cache-Control、ETag和Last-Modified，让重复加载走协商缓存，降低真实并发压力 - 对高清图做服务端自适应：根据
Accept头或客户端 DPR 动态返回合适尺寸，避免“先下大图再缩放”的带宽浪费
