仅靠id和src动态赋值无法实现多video真正同步，因html要求id唯一且各实例独立解码渲染；真同步需javascript主控事件桥接或capturestream()流共享。
直接用 id 绑定动态源无法实现真正同步——它只解决元素定位，不处理时间轴、状态、音量等联动逻辑。真同步必须靠 JavaScript 主控 + 事件桥接，或底层流共享。
为什么仅靠 id 和 src 动态赋值做不到同步
给多个 <video></video> 元素设相同 id 是非法的（HTML 规范要求唯一），而用不同 id 获取元素后分别设 src，只是让它们加载同一文件，并不自动共享播放进度、暂停状态或音量。常见错误现象包括：拖拽一个视频进度条，另一个卡在原位置；点击一个的播放按钮，另一个无响应；调大主视频音量，音频轨道仍静音。
-
src更改会触发重新加载，currentTime重置为 0，无法保持“同一时刻” - 浏览器对每个
<video></video>实例独立解码和渲染，没有内置时间轴对齐机制 - 移动端尤其明显：iOS Safari 对并发
play()调用有严格限制，常只允许一个有声媒体启动
captureStream() 是目前最可靠的双视频同步方案
当两个视频内容完全一致（如原画 vs 滤镜版），captureStream() 把源视频输出转为实时流，直接喂给目标视频，二者帧级一致。它绕过了手动同步 currentTime 的误差累积，也规避了重复解码开销。
- 必须为源视频添加
crossorigin="anonymous"，否则跨域资源会触发 “tainted canvas” 错误导致captureStream()返回空流 - 目标视频不能设
src，必须用srcObject = stream；设src后再赋srcObject会清空原有资源 - 旧版 Safari（≤16.4）和所有 IE 不支持该 API，需降级到事件监听方案
- 注意：该方法只转发视频轨道；若需同步音频，源视频必须开启
audio输出（即未被muted或禁音）
纯 JavaScript 主从控制的关键事件与节流点
当 captureStream() 不可用，或需同步音频+视频混合场景时，必须手动桥接状态。核心不是“同时调用 play()”，而是统一响应主元素事件并修正从属元素偏差。
- 监听主元素的
play、pause、timeupdate、volumechange、ratechange五类事件 -
timeupdate频率太高（每 200ms 左右一次），直接赋值currentTime易引发抖动；建议用requestAnimationFrame节流，或只在拖拽结束（seeking→seeked）后校准一次 - 设置
currentTime前，检查从属元素是否已触发loadedmetadata，否则可能静默失败 - 音量同步必须双向：主视频
volumechange→ 同步audio.volume和audio.muted；反之亦然，否则自定义控件拖动音量条时从属端失联
autoplay 有声同步失败的唯一可靠解法
现代浏览器（Chrome ≥77、Firefox ≥66、Safari ≥15.4）默认拦截任何带声音的自动播放。即使你用 id 找到所有视频并循环调用 .play()，只要没满足用户手势前提，全部 Promise 都会 reject，且不报错——只在控制台输出 DOMException: play() failed because the user didn't interact with the document first。
- 加
muted属性可绕过限制：<video id="main" autoplay muted></video>，但此时音频通道关闭，无法用于需要播放声音的同步场景 - 真正有声同步，只能等用户首次交互（click/touchstart）后再统一调用
play()，且必须捕获每个 Promise：Promise.all([v1.play(), v2.play(), a1.play()]).catch(...) - 不要依赖
setTimeout延迟触发——用户手势窗口期极短（通常仅限当前事件循环），延后即失效
同步难点不在获取元素，而在维持时间轴一致性；id 只是入口，真正的同步逻辑藏在事件响应节奏、流绑定时机和浏览器策略适配里。漏掉 volumechange 双向监听或忽略 loadedmetadata 校验，都会导致看似能播、实则不同步的“伪成功”状态。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
