WebSocket是实现同步影院实时双向通信的核心技术，关键在于统一控制逻辑、处理延迟与状态同步，而非单纯发送时间戳。
WebSocket 可以实现实时双向通信，是构建同步影院（多端视频播放进度一致）的核心技术。关键不在于单纯“发时间”，而在于统一控制逻辑、处理延迟、容错和状态同步。
服务端：建立 WebSocket 连接并管理播放会话
每个同步房间对应一个唯一 room ID，服务端维护该房间内所有客户端的连接列表及最新同步状态（如当前播放时间、播放/暂停状态、是否为主控端）。当任一客户端发送播放控制指令（如 seek 到 128.5s、pause、play），服务端不做判断，直接广播给同房间其他所有客户端（除发送方）。
- 使用轻量级后端（如 Node.js + ws 库）即可承载数十人房间
- 避免存储历史状态，只保留“当前权威状态”，降低复杂度
- 为防消息乱序，可添加简单序列号或时间戳，客户端忽略过期指令（例如收到 t=130 的 seek，但本地已播到 135，则跳过）
客户端：监听控制指令并精准响应视频元素
前端监听 WebSocket 消息，拿到指令后调用 video.currentTime 和 video.play()/pause()。注意不能直接赋值后立刻播放——浏览器可能因自动播放策略拒绝无用户交互的 play() 调用。
- 对 seek 操作：先设置 currentTime，等待 seeked 事件触发后再执行播放/暂停，确保画面已就位
- 对 play/pause 指令：若当前处于静音或未交互状态，可先尝试 video.muted = true 并触发一次空 play() 建立播放上下文
- 主控端本地操作也需先发指令再执行，保证“发出即生效”，避免本地快于远端造成抖动
处理网络延迟与不同步问题
纯广播机制下，各客户端因网络延迟、解码性能、JS 执行时机差异，仍可能出现 ±200ms 级别偏差。需叠加补偿策略：
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
立即学习“前端免费学习笔记（深入）”；
- 启用 video.playbackRate = 1.005 或 0.995 微调追赶/拖慢（仅临时，持续数秒后恢复）
- 定期（如每 10 秒）主动上报本地 currentTime 给服务端，服务端比对后向偏差 >500ms 的客户端推送校准指令
- 暂停期间不校准；播放中连续 3 次校准失败则提示“网络不稳定”，建议重连
补充体验细节
同步影院不是技术炫技，而是服务观影体验：
- 显示“主控者昵称”和“延迟 ms”，让用户感知同步质量
- 允许房主指定某人为临时主控（权限移交），避免单点故障
- 视频加载阶段（waiting → canplay）禁止同步操作，防止 currentTime NaN 导致崩溃
- 断线重连后，从服务端拉取最新状态并 seek 到对应位置，而非继续本地播放
不复杂但容易忽略：同步的本质是“状态共识”，不是“时间镜像”。只要所有终端在任意时刻对“该播哪、该停哪”达成一致，哪怕画面帧略有先后，人眼也几乎无法察觉。真正影响体验的，往往是错误的异常处理和缺乏反馈的黑盒操作。
