必须用意图式消息结构（如{type:'seek',time:123.45}）替代裸状态同步，配合节流发送、就绪校验、错误兜底，才能解决视频未加载完成或休眠恢复导致的状态错位问题。
直接用 BroadcastChannel 就能同步播放进度和静音状态，但必须配合主动读取 + 明确消息结构，否则会出现“小窗已静音、主窗口还在响”或“进度条跳变”这类错位问题。
为什么不能只靠 postMessage(event.data) 里的 currentTime 和 muted 值
很多人在收到 message 后直接赋值 video.currentTime = event.data.currentTime，这看似合理，实则埋雷：
- 网络抖动或快速拖拽时，多个
timeupdate消息可能乱序到达，用裸数据会覆盖最新状态 -
event.data.muted是发送时刻的快照，但接收方视频元素可能正处在loadedmetadata之前，此时设置muted无效，且不会抛错 - 主窗口暂停后发了
{ type: 'pause' }，小窗还没加载完视频，pipVideo.pause()会静默失败
正确做法是：所有窗口统一以自身 video 元素为操作目标，广播只传意图（play/pause/seek），不传中间态。
推荐的消息结构与收发逻辑
用 type 字段区分行为，避免歧义；关键字段只传必要参数，不塞冗余状态：
- 播放控制：
{ type: 'play' }、{ type: 'pause' }、{ type: 'togglePlay' } - 进度跳转：
{ type: 'seek', time: 123.45 }（只传目标时间，不传当前时间） - 静音切换：
{ type: 'toggleMute' }（不传muted: true/false，避免状态漂移） - 音量变更：
{ type: 'setVolume', volume: 0.7 }（范围 0–1）
发送端监听 video 事件时要节流：
let lastSeekTime = 0;
video.addEventListener('timeupdate', () => {
const now = Date.now();
if (now - lastSeekTime > 200) { // 防止高频抖动
channel.postMessage({ type: 'seek', time: video.currentTime });
lastSeekTime = now;
}
});
接收端必须做状态校验再操作
收到消息后不能无脑执行，要先检查视频是否就绪、是否允许自动播放等前置条件：
- 对
seek：先判断pipVideo.readyState >= 1（至少有元数据），否则缓存pendingSeek = time，等loadedmetadata后再执行 - 对
toggleMute：先读pipVideo.muted，再调用pipVideo.muted = !pipVideo.muted，避免因异步导致重复 toggle - 对
play：需await pipVideo.play().catch(() => {})，静默忽略自动播放策略拒绝
特别注意：Chrome 对后台标签页的 play() 调用会直接 reject，此时应降级为仅更新 UI 状态，不强行触发播放。
频道生命周期与错误兜底
BroadcastChannel 实例必须和页面生命周期绑定，否则容易内存泄漏或消息错乱：
- 创建时机：页面 DOM 加载完成、
video元素存在后立即初始化，如document.addEventListener('DOMContentLoaded', () => { channel = new BroadcastChannel('media-sync'); }) - 关闭时机：在
beforeunload或 Vue/React 组件onUnmounted中调用channel.close()，不要等到visibilitychange再关 - 断连兜底：监听
channel.onmessageerror，若连续 3 秒无消息，可 fallback 到每 5 秒轮询一次localStorage.getItem('lastMediaState')（仅当document.visibilityState === 'visible'时）
真正难处理的不是同步本身，而是「视频未加载完成时收到控制指令」和「页面被系统休眠后恢复时的状态错位」——这两个点必须在接收逻辑里显式防御，不能依赖广播的实时性。
