AudioContext.currentTime与video.currentTime不同步因基准不同：前者基于音频硬件时钟，后者依赖渲染帧调度与解码延迟；应以video.currentTime为主时间轴，动态校准偏移并持续监控丢帧。
AudioContext.currentTime 和 video.currentTime 为什么总对不上
HTML5 音画不同步，八成是因为你直接拿 AudioContext.currentTime 去对齐 video.currentTime——它们压根不在同一时间基准上。AudioContext 的时间戳是音频硬件时钟驱动的，而 video 是渲染帧调度+解码延迟混合的结果，两者漂移是常态。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 别用
AudioContext.currentTime做音画同步依据，它只适合音频内部节拍控制（比如 Web Audio API 节奏器） - 以
video.currentTime为唯一主时间轴，所有音频调度都基于它推算：先查video.currentTime，再用audioContext.resume()+start(when)精确到毫秒级触发 - 如果必须做动态校准，每 200ms 读一次
video.currentTime，对比音频已播放时长（可用audioElement.currentTime或 Web Audio 的analyserNode推算），差值 > 40ms 就重调度
requestVideoFrameCallback 为什么没解决同步问题
这个 API 看起来很理想——“在视频帧渲染前回调”，但实际落地时，它只保证回调时机接近帧渲染，不保证音频也刚好卡在这个点输出。尤其在低端设备或高负载下，requestVideoFrameCallback 回调可能延迟 1–3 帧，而音频缓冲区早已填满。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 不要在
requestVideoFrameCallback回调里直接调audioContext.start()，容易触发隐式暂停/恢复抖动 - 用它来更新时间戳和校准偏移量即可，音频调度仍走
audioContext.currentTime+when参数预计算方式 - 注意兼容性：
requestVideoFrameCallback在 Safari 16.4+ 和 Chrome 112+ 才稳定支持，旧版本需 fallback 到requestAnimationFrame+video.getVideoPlaybackQuality()查丢帧
Web Audio 的 bufferSource.start(when) 怎么设才不跳
bufferSource.start(when) 的 when 不是相对当前时间，而是相对于 audioContext.currentTime 的绝对时间点。很多人写成 start(audioContext.currentTime + offset)，结果 offset 算错、上下文暂停、或 audioContext 还没 resume，就导致音频突兀开始或完全不响。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 确保调用前已执行
audioContext.resume()，且检查audioContext.state === 'running' - offset 计算必须基于最新
video.currentTime，不是初始值；例如：想让音频比视频快 80ms，就设start(audioContext.currentTime + (video.currentTime - 0.08))—— 注意括号优先级 - 避免连续高频调用
start()，Web Audio 对重复 start 有静音保护，可改用gainNode.gain.setValueAtTime()控制启停
MediaRecorder 录制后音画偏移怎么修
用 MediaRecorder 同时录 video 和 audio 轨道，导出文件经常音快画慢，这是因为浏览器内部采集线程不同步，且 MediaRecorder 对音视频时间戳打标策略不透明。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 放弃单个
MediaRecorder录双轨，改用分离录制：一个录canvas.captureStream().getVideoTracks()[0]，另一个录audioContext.createMediaStreamDestination().stream.getAudioTracks()[0] - 录制前手动对齐：先
video.play()，等video.readyState >= HTMLMediaElement.HAVE_CURRENT_DATA后，再启动两个 recorder - 导出后必须用 FFmpeg 重 mux，命令如：
ffmpeg -i video.webm -i audio.webm -c copy -shortest -vsync vfr output.mp4，否则浏览器自带 muxer 会瞎猜 PTS
时间轴校准不是一次性设置就能搞定的事，它得在播放中持续观测、微调、容错。最容易被忽略的是：不同设备上 video.getVideoPlaybackQuality() 返回的 droppedVideoFrames 和 corruptedVideoFrames 差异极大，而这些指标恰恰是决定是否该主动丢帧重对齐的关键信号。
