应统一用 AudioContext 时间线驱动，避免混用 currentTime；解码延迟需预加载并用 context.currentTime 精确调度；卡顿需检查 networkState 和 buffered；iOS 必须用户手势触发 resume() 并确保 44.1kHz 采样率。
音频延迟明显，AudioContext 时钟和 currentTime 不一致怎么办
HTML5 音频延迟往往不是“播放慢”，而是时间戳错位导致的同步失控。比如用 AudioContext.currentTime 计算播放位置，但实际 audioElement.currentTime 已滞后 200ms 以上——这说明你混用了两个不同精度、不同起点的时间系统。
-
AudioContext.currentTime是高精度、单调递增的音频渲染时钟（单位秒），从上下文创建起计，不受系统休眠影响 -
HTMLMediaElement.currentTime是基于媒体缓冲和解码状态的粗略时间（单位秒），会因卡顿、seek、网络抖动跳变 - 若用
AudioContext控制播放时机（如 Web Audio 节拍器），却拿audioElement.currentTime做校准，必然漂移 - 解决方法：统一用
AudioContext时间线驱动；若必须对接 media element，用audioElement.getStartDate()（需 Chrome 117+）或监听timeupdate+performance.now()手动拟合偏移
decodeAudioData 解码慢、播放首帧延迟高
调用 decodeAudioData 后立即 start()，常出现“黑 silence”或延迟数百毫秒，本质是解码未完成就触发了播放调度。
- 解码是异步且耗 CPU 的，尤其对长 WAV/FLAC 或未压缩 PCM 数据；Chrome 中大文件可能阻塞主线程 50–200ms
- 不要在
then()回调里直接start(0)，而应记录解码完成时刻，并用context.currentTime精确调度：source.start(context.currentTime) - 预加载阶段可提前调用
decodeAudioData并缓存AudioBuffer，避免运行时解码瓶颈 - 对实时性要求高的场景（如乐器应用），优先选用
createMediaStreamSource+MediaRecorder绕过解码，或用 WASM 解码器（如 ffmpeg.wasm）接管控制权
播放卡顿、断续，onstalled 和 onwaiting 频发
这不是音频 API 的问题，而是媒体资源加载或解码管道断裂。关键看触发时机：onstalled 表示浏览器已放弃加载（通常因网络失败或 CORS），onwaiting 表示有数据但不够继续播放（缓冲不足）。
- 检查
audioElement.networkState：值为0（NETWORK_EMPTY）或1（NETWORK_IDLE）说明没连上；2（NETWORK_LOADING）正常；3（NETWORK_NO_SOURCE）是 src 无效 - 监控
audioElement.buffered：用buffered.end(0) - audioElement.currentTime算剩余缓冲时长，低于 0.5s 就该主动load()或切换低码率源 - 避免在
autoplay未被用户手势激活时设置src，否则 Chrome 会静音并延迟加载，触发虚假卡顿 - 服务端加
Accept-Ranges: bytes和合适Content-Range，让浏览器支持分段加载；MP3 不支持流式解码，优先用 MP4（AAC）或 Opus（WebM）
移动端 iOS Safari 播放无响应、延迟翻倍
iOS 对 Web Audio 和 <audio></audio> 有硬性限制：必须由用户手势触发首次播放，且音频上下文默认被挂起（state === "suspended"），不手动恢复就永远不响。
立即学习“前端免费学习笔记（深入）”；
- 首次播放前必须绑定到用户事件（如
click、touchend），并在回调中调用context.resume()和audioElement.play() - iOS Safari 的
AudioContext采样率固定为 44.1kHz，若传入 48kHzAudioBuffer，会强制重采样，引入额外延迟；服务端应统一输出 44.1kHz - 禁用
webkit-playsinline外的自动全屏行为（如微信内置浏览器），否则播放器切出页面后音频被暂停，再切回不会自动恢复 - 真机调试用 Safari 开发者工具 → “Timelines” 标签页，勾选 “Audio” 和 “Script Profiler”，可定位是 JS 卡住还是音频线程阻塞
真正难处理的是跨设备时间漂移 + 移动端策略限制叠加的情况。比如 iOS 上 resume() 成功但 context.currentTime 仍为 0，或 Android Chrome 中 buffered 返回空对象——这些都不是代码写错，而是平台故意留的坑，得靠降级策略兜底。
