音画同步必须用JavaScript每帧读取audio.currentTime并实时驱动视觉，禁用ontimeupdate和定时器；移动端首次播放需用户手势同步触发；高精度场景须升级Web Audio API。
直接用 <audio></audio> 标签插入音频不等于音画同步——它只负责播放，不同步是默认状态；真同步必须靠 JavaScript 主动对齐时间轴，且 iOS/Android 有强制交互限制，跳过这一步必失败。
audio.currentTime 是唯一可信的时间源
动画帧（requestAnimationFrame）和音频解码节奏天然不同步，不能靠定时器“等”到某个时间点再触发画面。必须每帧读取 audio.currentTime，再算出当前该显示什么视觉状态。
- 不要在
audio.ontimeupdate里驱动关键动画：该事件延迟高（200–500ms）、触发不规律，只适合做进度条更新 - 若用 Canvas 动画，
requestAnimationFrame回调中直接读audio.currentTime，按比例映射到动画参数（如旋转角度、粒子位置） - seek 后必须监听
seeked事件并立刻重置视觉状态——audio.currentTime已变，但动画还卡在旧帧，不手动跳转就会脱节几秒 - 避免用
setTimeout或setInterval模拟同步：JS 时序不可靠，尤其在低端设备或后台标签页中会大幅漂移
移动端首次播放必须由用户手势触发
iOS Safari 和 Android Chrome 对音频启动最严：哪怕只播 1ms 静音，也必须在 click 或 touchstart 的同步回调里调 audio.play()，任何异步包装（setTimeout、Promise.then、事件委托链）都会静默失败。
- 典型错误：
document.addEventListener('DOMContentLoaded', () => audio.play())→ 必报DOMException: play() failed because the user didn't interact with the document first - 安全写法：绑定按钮点击，同步调用
audio.play().catch(e => console.warn('Play failed:', e)) - iOS 可用“静音解锁”策略：首次播放一个 1ms 的空音频（
new Audio('data:audio/wav;base64,u')），后续再播主音频就不再受限 - 检查
audio.readyState：至少为HTMLMediaElement.HAVE_ENOUGH_DATA（值为 4）再调play()，否则可能静默失败
高精度场景必须升级 Web Audio API
做节拍检测、频谱可视化或毫秒级音效调度时，<audio></audio> 的 currentTime 精度不足（受缓冲、解码抖动影响），且无法访问原始音频数据。必须用 AudioContext 接入分析节点。
立即学习“前端免费学习笔记（深入）”；
- 用
context.createMediaElementSource(audio)将已有<audio></audio>接入 Web Audio 图形，保持时间线一致 - 读取
analyser.getFloatFrequencyData()必须在requestAnimationFrame中进行，但时间基准仍用context.currentTime（比audio.currentTime更稳定） - iOS 上
AudioContext必须在用户手势后初始化并调context.resume()，否则后续所有节点都静音 - 不要依赖
AudioContext.baseLatency校正音画偏差：它是只读硬件最小延迟（10–100ms），与视频帧时间无关，不能用于 AV skew 计算
音画同步真正的难点不在“怎么播”，而在“怎么感知偏差+怎么安全校正”——audio.currentTime 提供了起点，但每次 seek、暂停恢复、网络抖动、iOS 权限切换，都会让这个时间点突然失准，必须在每个环节做防御性检查和重同步。
