基于navigator.connection监测网络变动动态调整视频清晰度权重

先摆核心结论：想靠 network.connection.change 事件来无缝切换视频清晰度？大概率会失望。这个事件只在关键时刻“掉链子”——它只在网络类型或下行带宽发生显著跳变时才会触发。但对于视频播放来说，更常见的场景是带宽“温水煮青蛙”式的缓慢下降，这恰恰是流畅变卡顿的开始。

network.connection.change 事件是否可靠？（实战告诉你答案）

结论很直接：不完全可靠。浏览器内置的机制决定了，它只在 effectiveType（如从“4g”跳到“slow-2g”）或 downlink 值发生“显著变化”时才触发事件。

问题就出在“显著”这个词上。什么叫显著？从4.8 Mbps掉到4.2 Mbps，这对人眼感知的流畅度可能是灾难性的，但浏览器可能觉得这只是个小波动，change 事件根本不响应。

所以，把清晰度切换的逻辑全押在这个事件上，相当于把视频流畅度交给了不确定的运气。实战中的标准做法是“轮询为主，事件为辅”。必须建立一个定时的“健康检查”机制，比如每3到5秒主动去读取一次 navigator.connection.downlink 和 effectiveType，再结合视频当前的播放和缓冲状态，综合判断是否需要切换。

这里有三个关键细节：
轮询间隔别设太短，频繁读取可能引发性能问题；
首次加载时就必须立刻读取一次，不能傻等第一个 change 事件来初始化网络状态；
兼容性是老生常谈但必须提：Safari 15.4+才完全支持，更老的版本或者不支持的环境，得用 navigator.onLine 结合历史片段加载耗时来估算。

downlink 值怎么用才不翻车？（理解其本质）

拿到 downlink 这个以 Mbps 为单位的浮点数时，先别急着高兴。你必须清楚，它不是实时的网速测试结果，而是浏览器基于历史RTT（往返时间）、丢包率和协议栈行为给出的一个“保守估算”。

这就带来两个典型现象：一是Chrome等浏览器给出的值通常比实际测速软件的结果低20%-40%，这是“保守”的体现；二是在弱网环境下，这个值可能剧烈抖动，比如短短几秒内在0.8、1.3、0.6之间反复横跳。

因此，直接用 if (downlink > 5) { 切1080p } 这种简单逻辑，误判率会非常高。稳妥的做法是引入缓冲区间和防抖机制：
设置三级阈值区间：例如，downlink >= 8 走高清（1080p），3 走标清（720p），downlink 走流畅（480p）。
连续确认才执行：至少连续2次轮询采样都落在同一个清晰度档位，才触发切换动作，这能有效过滤掉单次的瞬时毛刺。
看准时机再动手：切换前，务必检查视频是否正在缓冲。如果 video.buffered.length > 0 && (video.buffered.end(0) - video.currentTime) ，说明缓冲不足，这时候强行切换清晰度可能会雪上加霜，正确的做法是延迟切换。

如何让 Svelte/Vue/React 组件响应式地绑定 network 状态？（框架实战）

一个常见的误区是试图把 navigator.connection 这个原生对象直接丢进Vue的ref、React的state或者Svelte的store里，然后指望框架自动监听它的变化——这是行不通的，因为它本身不是响应式对象，属性变化也无法被直接侦测。

正确的模式是，封装一个可订阅的“状态源”。在这个状态源内部，通过轮询或事件来手动更新数据，从而驱动框架的响应式系统。

以Svelte为例，一个清晰的实现是使用 derived store配合定时器：

import { derived, get } from 'svelte/store';
import { networkStatus } from './stores'; // 这是一个你定义的可写store

const connection = navigator.connection;
const pollInterval = 3000;

// 创建一个派生store，其值基于我们轮询更新的networkStatus
const networkSignal = derived(networkStatus, ($status) => {
  if (!connection) return { effectiveType: '4g', downlink: 5 }; // 降级处理
  return {
    effectiveType: connection.effectiveType,
    downlink: connection.downlink,
    saveData: connection.saveData
  };
});

// 启动轮询的函数（注意：应在组件onMount中调用，避免SSR问题）
function startNetworkPolling() {
  const id = setInterval(() => {
    // 重新读取navigator.connection并更新核心store
    networkStatus.set({ /* 更新网络状态数据 */ });
  }, pollInterval);
  return () => clearInterval(id); // 返回清理函数
}

Vue和React的思路完全一致：不要去watch navigator.connection，改为watch你自己封装的响应式状态变量，并在 `setup`/`useEffect` 等生命周期钩子中管理轮询定时器的创建与销毁。

切换视频源时最容易忽略的两个坑（细节决定成败）

搞定了网络监测和状态绑定，切视频源本身也有“暗礁”。第一坑是，更换 video.src 后，如果不同步处理 currentTime，视频会默认从头开始播放，用户观感瞬间跳戏。

第二坑更隐蔽，在iOS Safari上尤为突出：没等 loadedmetadata 事件触发就急着调用 `play()`，这个Promise很可能被拒绝，导致自动播放失败。

因此，切换时必须遵循严格流程：
更新 src 后，先监听 loadedmetadata 事件；
事件触发后，立刻恢复之前的播放位置：`video.currentTime = prevTime`；
如果你的场景是静音自动播放（比如信息流视频），切换后需要显式设置 video.muted = true 再调用 `play()`，否则iOS的策略可能会拦下你；
别忘了清理旧资源，如果之前用了 srcObject（如WebRTC流），要记得释放，避免内存泄漏。

话说回来，这类功能真正的难点，往往不在于“如何切换”，而在于“何时不该切换”。比如用户正在拖拽进度条、刚刚手动点了暂停、或者视频因为缓冲不足正在“转圈”加载——在这些边界状态下，任何自动的清晰度切换都可能干扰用户体验，做得不好甚至比手动切换还卡。识别并优雅处理这些场景，才是实现真正智能自适应切换的关键。