Web Audio API 不能直接控制 播放，需用 createMediaElementSource() 接入音频流，并在用户手势中调用 audioContext.resume() 后再播放；currentTime 跳转受关键帧和缓冲影响，切换 src 需先断开旧源并重连，移动端需注意自动播放限制与上下文恢复。
Web Audio API 不能直接操作 或 元素的播放/暂停，它只处理音频数据流；而视频控制（如跳转、静音、全屏）必须通过 DOM API 操作元素本身。两者要协同工作，得靠 HTMLMediaElement 的事件和方法桥接。
如何把
关键在于用 AudioContext.createMediaElementSource() 创建音频源节点，而不是直接播放媒体元素。一旦接入， 的播放/暂停需由 AudioContext 状态驱动，否则会触发“无法在已暂停上下文中启动”的错误。
-
AudioContext必须在用户手势（如click、touchstart）中首次调用resume()，否则后续createMediaElementSource()会失败 - 不要调用
video.play()单独播放 —— 应先audioContext.resume()，再连接节点，最后调用video.play()（或让MediaElementAudioSourceNode自动拉取） - 若需静音但保留视频画面，设
video.muted = true，而非移除音频节点；移除节点会导致音频流中断且无法无损恢复
const video = document.getElementById('myVideo');
const audioContext = new (window.AudioContext || window.webkitAudioContext)();
let sourceNode = null;
document.getElementById('startBtn').addEventListener('click', async () => {
await audioContext.resume(); // 必须在用户交互中调用
sourceNode = audioContext.createMediaElementSource(video);
// 加个简单增益节点做演示
const gainNode = audioContext.createGain();
gainNode.gain.value = 0.7;
sourceNode.connect(gainNode);
gainNode.connect(audioContext.destination);
await video.play(); // 此时才真正开始解码+播放
});
为什么 video.currentTime 设置后不生效或跳转不准
本质是浏览器对媒体缓冲与解码时机的控制权问题。currentTime 是异步操作，设置后立即读取可能仍为旧值；且 H.264/WebM 等编码依赖关键帧（I-frame），若目标时间点附近无关键帧，浏览器会向前回退到最近的关键帧再开始解码。
- 监听
seeking事件确认跳转是否启动，seeked事件确认完成 - 避免高频设置
currentTime（如拖拽过程中每毫秒设一次），应节流或改用requestVideoFrameCallback（Chrome 110+）同步视觉反馈 - 使用
video.buffered判断目标时间是否已缓存，未缓存时设currentTime会触发重新加载并延迟
如何安全地切换 src 并保持音频处理链不崩溃
直接改 video.src 会重置整个媒体状态：已连接的 MediaElementAudioSourceNode 失效，currentTime 归零，且 AudioC 不会自动感知变化。强行复用旧节点会抛出 
InvalidStateError。
- 切换前先调用
sourceNode.disconnect()，再设新src - 新
src加载完成后，在loadedmetadata回调里重建MediaElementAudioSourceNode - 若需保持增益、滤波等效果状态，把效果节点（如
gainNode、biquadFilter）保留在图中，只替换sourceNode并重新connect()
video.addEventListener('loadedmetadata', () => {
if (sourceNode) sourceNode.disconnect();
sourceNode = audioContext.createMediaElementSource(video);
sourceNode.connect(gainNode); // 重连已有效果节点
});
移动端视频自动播放与音频上下文恢复的常见陷阱
iOS Safari 和 Android Chrome 对自动播放限制极严：video.play() 必须在用户手势中调用，且 AudioContext 的 resume() 也受同一限制。更隐蔽的问题是：某些安卓 WebView 中，即使用户点过按钮，AudioContext 在后台切回前台后仍可能被挂起，需再次 resume()。
- 不要依赖
autoplay属性 —— 它在多数移动浏览器中被忽略或强制静音 - 在
visibilitychange事件中检查audioContext.state === 'suspended'，是则尝试resume()（但需包裹在用户可触发的回调里，比如一个隐藏的click监听器） - 对 iOS，
video.muted = true+autoplay才有可能自动播放画面（但无声音），这是唯一绕过限制的合法方式
最易被忽略的一点：Web Audio API 的时间戳（如 audioContext.currentTime）和 video.currentTime 完全不同步 —— 前者是音频渲染时钟，后者是媒体解码时钟，差值可能达数百毫秒。做音画同步时，别直接拿两者相减校正，要用 video.getVideoPlaybackQuality() 或 performance.now() 结合帧时间戳做动态补偿。
