navigator.connection.rtt 是最直接稳定的加载阈值依据，因其反映真实链路响应速度；应分段映射 RTT 为 scrollThreshold 并与 window.innerHeight 挂钩，设下限防过小，配合防抖和 fallback 机制保障稳定性。
navigator.connection.rtt 是最直接、最稳定的依据，比 effectiveType 或 downlink 更适合调节加载阈值——它反映的是真实链路响应速度，而不仅是运营商标注的“4G”或带宽估算值。RTT 高时，提前太多加载反而导致请求堆积和超时；RTT 低时，可以更激进地预取，减少用户等待感。
为什么不能只看 effectiveType 就设固定阈值
浏览器对 effectiveType 的判断存在滞后性和粗粒度问题：比如用户刚从地铁进入商场WiFi，effectiveType 可能还维持着 slow-2g，但实际 RTT 已降到 30ms；又或者在弱信号 4G 下，effectiveType 显示 4g，而 RTT 实际超过 300ms。此时若按 4g 设置 800px 阈值，极易触发大量失败预加载。
更可靠的做法是用 rtt 做主干判断，effectiveType 仅作 fallback 或辅助校验：
- 当
rtt可用（非undefined）且数值合理（通常 10–500ms），优先采用它计算阈值 - 当
rtt === 0或明显异常（如 >1000ms），回退到effectiveType查表：'wifi'→600px，'4g'→400px，'3g'→200px，'2g'/'slow-2g'→100px - 始终限制最小阈值不低于 100px，避免滚动未动就触发请求
如何把 RTT 映射为滚动加载阈值（scrollThreshold）
阈值不是线性缩放，而是分段映射：低延迟下可大幅提前加载，高延迟下必须保守。推荐使用以下经验公式，已在多个 SPA 生产环境验证：
function getScrollThreshold() {
const conn = navigator.connection;
if (!conn || conn.rtt === undefined) return 400;
<p>const rtt = conn.rtt;
if (rtt <= 50) return Math.max(600, window.innerHeight <em> 2);
if (rtt <= 150) return Math.max(300, window.innerHeight </em> 1.2);
if (rtt <= 300) return Math.max(150, window.innerHeight <em> 0.8);
return Math.max(100, window.innerHeight </em> 0.5);
}关键点：
- 所有结果都与
window.innerHeight挂钩，确保在不同屏幕尺寸下语义一致（例如“提前两屏”比“提前600px”更合理） - 每档都设了下限（
Math.max），防止小屏设备算出过小值（如手机上innerHeight * 0.5可能仅 250px，但必须保证至少 100px） - 不依赖
downlink，因其单位是 Mb/s、波动大、且部分 Android 浏览器返回值恒为 1.0
监听变化时要防抖 + 降级兜底
connection.change 事件可能高频触发（尤其在移动网络切换瞬间），直接重算阈值并重置 infinite-scroll 实例会导致 UI 跳变或请求中断。必须加简单防抖，并在不支持 API 时提供静态 fallback：
- 用
setTimeout延迟 500ms 执行阈值更新，连续触发只留最后一次 - 首次初始化时就调用
getScrollThreshold()，不要等事件——很多用户根本不会触发 change - 若
'connection' in navigator为 false（如 Safari 旧版、微信内置浏览器），默认用window.innerHeight * 1.2（约 400–500px），比纯 400px 更适应现代内容密度 - 避免在 change 回调里重新 new InfiniteScroll 实例，应调用已有实例的
updateSettings({ scrollThreshold: newThreshold })（如使用infinite-scroll@4+）
真正容易被忽略的是：RTT 是单次估算值，不代表整体会话质量。它可能在一次页面生命周期内变化多次，但你不需要每次变化都调整阈值——重点在于首次加载和网络类型突变（如 WiFi 切 4G）时的响应精度。其他时候，保持当前阈值稳定比频繁微调更重要。
