timeupdate 事件在 Chrome 本地预览中滞后 100–300ms，因其触发依赖渲染帧率、主线程负载和缓冲策略，最小间隔约 200–400ms，不可配置，且 file:// 协议下缺乏服务端时钟对齐与网络缓冲平滑机制。
为什么 timeupdate 事件在 Chrome 预览里总滞后 100–300ms？
HTML 媒体元素（<video> 或 <audio>）的 timeupdate 事件本身不保证实时性——它只在浏览器认为“合适的时候”触发，通常受渲染帧率、主线程负载和内部缓冲策略影响。你在本地文件预览（file:// 协议）中调试时，尤其容易观察到时间戳跳变、事件漏发或延迟，因为缺少服务端时钟对齐与网络缓冲平滑机制。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 别依赖
timeupdate做亚帧级同步（如唇形对齐），它最小触发间隔约 200–400ms，且不可配置 - 改用
requestVideoFrameCallback（Chrome 111+）或performance.now()+getVideoPlaybackQuality()辅助估算真实播放时刻 - 本地预览务必加
crossorigin="anonymous"属性，否则部分 API（如getVideoPlaybackQuality）会静默失效
如何用 play 和 waiting 事件判断视听是否真正“卡住”？
用户感知的“不同步”，常源于音频已播但视频帧未解码完成，或反之。单纯监听 play 并不表示媒体已进入稳定播放状态；而 waiting 触发后若未接续 playing，大概率是解码阻塞。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 监听
waiting后启动一个 500ms 计时器，超时未收到playing就标记为“解码卡顿” - 对
<video>元素调用video.getVideoPlaybackQuality()，检查droppedVideoFrames是否持续增长 - 避免在
play回调里立即读取video.currentTime——此时值可能仍是 0 或上一帧时间，应等首个timeupdate或playing后再采样
怎样让 seeking 事件在本地预览中可靠触发？
在 file:// 协议下，部分浏览器（尤其是 Safari 和旧版 Edge）对本地视频的随机访问支持不完整，导致 seeking 不触发、seeked 永不到达，或 currentTime 设置后无响应。
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 给
<video>加preload="metadata"，强制提前加载关键帧索引（对 MP4 尤其重要） - 设置
currentTime后手动检查video.seeking === true，若为false则说明 seek 被忽略，需降级为重新load()+play() - 避免在
loadedmetadata之前调用currentTime = x，此时浏览器尚未解析时长，赋值会被丢弃
为什么 canplaythrough 在调试时几乎没用？
canplaythrough 的设计意图是“当前缓冲足以连续播放到结束”，但它依赖浏览器对带宽和解码速度的粗略预测，在本地文件场景下该预测完全失效——所有字节都已在磁盘，但浏览器仍可能因未预加载足够帧而迟迟不触发。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 调试阶段直接监听
loadeddata（首帧已解码）或canplay（至少有 1 秒缓冲），比canplaythrough更可控 - 若需确保某时间点可精准跳转，用
video.readyState >= HTMLMediaElement.HAVE_FUTURE_DATA判断，它表示“后续若干帧已就绪” - 不要在
canplaythrough回调里立刻 start() 自定义同步逻辑——此时音频/视频解码器可能尚未完成初始化，首帧时间戳仍不准
真正难的不是监听哪个事件，而是理解每个事件背后的实际解码状态。本地预览没有服务端日志、没有网络 QoS 数据，只能靠 getVideoPlaybackQuality()、performance.now() 和反复验证 readyState 变化来交叉印证。别信事件名，要信你读到的值。
