Web Audio 切歌后按钮误复位？检查旧节点的 ended 回调

预览 B 已经开始，按钮却从“停止”跳回“播放”。Web Audio 的 ended 在源停止时触发，主动 stop 也可能触发。收到事件后，应用需要知道结束的是哪一次播放。

做一次 A 切 B 的对照

播放 A 后立即切 B，为两次播放分配不同标识，并记录切换请求、节点停止和 ended 到达顺序。先更新当前播放标识，再停止旧节点。A 的结束回调可以清理 A 的连接，但只有标识仍等于当前播放时才更新按钮。

区分结束原因与业务推进

若自然结束应自动进入下一段，在主动停止前记录取消意图。分别测试自然播完、按停止和快速 A→B→A。验收时确认旧回调既不会推进播放队列，也不会清除最新节点的引用。

参考官方资料与相关排查指南。可用音效生成工具查看或准备兼容素材，运行时行为在目标项目中验证。

把三种结果写成可重复的测试

1. 让 A 自然播完。记录 A 的标识、结束原因和队列位置。预期界面只完成一次收尾，队列按产品规则推进一次。
2. 播放 A 后点停止。先在 A 的记录上标记手动停止，再调用 stop。预期界面回到可播放状态，队列留在当前位置。
3. 快速执行 A → B → A，给每次播放分配独立标识，例如 41、42、43。即使两次选了同一文件，也不能用文件名判断事件属于谁。故意延后处理 41 的回调，预期 43 仍显示正在播放。

处理回调时分开清理节点和更新界面

每个回调闭包保存自己的节点和播放标识。旧节点可以断开自己的连接。需要清除当前引用、更新按钮或推进队列时，再判断这个标识是否仍是当前值。日志最少保留事件、标识、取消原因和当前标识。例如“ended，41，替换，当前43”意味着只清理41。若替换流程涉及异步解码，单独校验较晚返回的解码结果仍属于最近请求，再创建新节点。

验收时检查快速点击、自然结束和停止三个分支。把按钮状态、当前节点引用和队列位置一起记下来，避免界面看起来正常却丢失正在播放的节点。