AudioContext.currentTime不能直接用于高精度节奏对齐，它仅提供理论时间戳；精准对齐需结合start(when)调度、节拍时间线计算及音频事件时间戳，避免轮询导致的5–20ms误差。
AudioContext.currentTime 本身不能直接用于高精度节奏对齐，它只是返回当前音频上下文的“理论时间戳”，单位为秒，精度虽高（通常亚毫秒级），但不反映实际播放位置或节拍相位。真正实现音乐节奏对齐的关键，在于结合定时调度（scheduler）、音频事件时间戳（如 onended、start(when)）和节拍计算逻辑，而非依赖 currentTime 实时读取来“追赶”节拍。
理解 currentTime 的定位与局限
AudioContext.currentTime 是一个只读属性，表示从上下文创建起经过的秒数，基于高精度单调时钟（如 performance.now()）。它稳定、连续、不受音频卡缓冲或丢帧影响——但这恰恰意味着：
- 它不随音频播放进度同步（比如暂停后继续，
currentTime仍持续增长）； - 它不等于当前正在播放的样本位置（需换算：位置 =
currentTime × sampleRate，但仍有调度延迟）； - 单纯轮询
currentTime并做 if-else 判断节拍点，会因 JS 执行延迟、事件循环抖动导致 ±5–20ms 误差，无法满足音乐级对齐（如 120BPM 下每拍 500ms，±10ms 已明显偏移）。
用 start(when) + 节拍时间线实现精准调度
正确做法是：预先计算每个节拍/音符应开始的时间点（以 context.currentTime 为基准），再用 audioNode.start(when) 提前调度。浏览器音频引擎会在目标时间点附近精确触发，误差通常
- 设 BPM = 120，则一拍 = 60 / 120 = 0.5 秒；四分音符时长 = 0.5s；
- 获取当前参考时间：
const now = context.currentTime; - 计算下一个强拍时间：
const nextDownbeat = Math.ceil(now / 0.5) * 0.5; - 调度鼓声在强拍开始：
kickSource.start(nextDownbeat); - 后续音符按相对偏移叠加，如八分音符在
nextDownbeat + 0.25启动。
结合 AudioWorklet 或 ScriptProcessorNode 获取真实播放相位（进阶）
若需实时响应播放中的节奏（如 VJ 视觉同步、动态节拍检测），可使用 AudioWorklet 在音频线程中分析波形过零或能量峰值，并将相位信息通过 port.postMessage() 发送到主线程。此时：
立即学习“前端免费学习笔记（深入）”；
- AudioWorklet 内部时间由
currentTime（即AudioWorkletGlobalScope的currentTime）提供，与AudioContext.currentTime对齐； - 你可在 worklet 中计算“当前处于第几拍的第几分之一”，再传回主线程驱动动画或触发事件；
- 避免在主线程用
requestAnimationFrame或setTimeout反推节拍——它们的定时精度远低于音频线程。
规避常见陷阱：不要轮询，不要用 setTimeout 对齐
以下写法是低效且不准的：
❌ 错误示例：function checkBeat() {
const t = context.currentTime;
if (Math.abs(t % 0.5) < 0.01) { // 试图捕捉整拍时刻
triggerVisual();
}
requestAnimationFrame(checkBeat);
}原因：RAF 不保证 16.7ms 精确间隔；JS 执行+判断耗时导致漏判；t % 0.5 的数值比较在浮点下不可靠。
✅ 正确替代：用 context.onstatechange 监听上下文状态变化，配合预调度 + 延迟补偿（如根据上次触发误差微调下次 when 值）。
