Discord JS v12音乐机器人 Broadcast Dispatcher resume()失效问题

该问题为Discord.js v12版本VoiceDispatcher组件的固有状态同步缺陷，与命令逻辑、fetched对象的存储取值无关：

• pause(true)传入的参数是静默暂停标记：API层会将对外暴露的dispatcher.paused属性设为true，但不会同步更新底层Opus编码流、UDP语音发送管道的内部暂停锁状态。
• resume方法的执行逻辑以底层管道的暂停锁状态为判断依据，而非对外暴露的paused属性：因为静默暂停没有正确设置管道锁，resume会判定音频流处于正常播放状态，直接跳过流恢复逻辑，但聊天提示仍会正常发送，形成“提示已恢复但音频未播放”的表现。
• 调试阶段验证的“先pause、再两次resume”临时方案，本质是通过重复调用方法对齐静默暂停造成的错位状态：第一次resume修正管道锁的错位标记，第二次resume才能真正触发音频流恢复，对应“第一次resume无效、第二次才生效且伴随轻微卡顿”的现象。

• 修改pause命令的调用逻辑，移除传给pause()方法的true参数：将fetched.dispatcher.pause(true)替换为fetched.dispatcher.pause()。无参调用的pause方法会同步更新所有对外属性、底层管道锁的状态，后续执行无参的fetched.dispatcher.resume()即可单次触发正常恢复。
• 若需要保留静默暂停的效果（避免pause操作触发dispatcher内置调试日志），不要使用连续调用方法的hack方案——该方案会清空一次音频缓冲区，造成可感知的轻微卡顿。可在resume执行前，手动将paused状态同步到语音管道层，再执行resume，不会产生流断流问题。
• 注意：resume方法的传参在Discord.js v12中已废弃，不要给resume()传入任何参数，额外传参会进一步触发状态不同步的bug。
• 移除resume命令中调试阶段新增的多余pause、重复resume逻辑，恢复原本的暂停状态校验分支即可，状态对齐后校验逻辑可完全正常工作。

内容的提问来源于stack exchange，提问作者Mr Ochoa