遇到同样的问题，目前已解决，分两部分详述：

一、分析问题

我的场景是用户录制语音完成后，自动播放一遍，用户可以点“重听”按钮再次播放。

我使用 InnerAudioContext 来实现播放语音的需求，录制语音完成后的自动播放是将 InnerAudioContext.src 赋值为录制完成后得到的 tempFilePath，并设置自动播放（InnerAudioContext.autoplay = true），可以正常播放，且 onTimeUpdate 回调正常。

第一遍播放完毕后，点击“重听”按钮时，我使用 InnerAudioContext.play()，倒是可以正常播放，但 onTimeUpdate 100%不会被触发（我需要用 onTimeUpdate 来更新进度条）。

发现这个问题下很多人已经指出，只要触发了 innerAudioContext.onWaiting，innerAudioContext.onTimeUpdate 就会失效，我实测了一下，果然如此：运行 InnerAudioContext.play() 后，就会触发 onWaiting，因为需要重新载入音频文件，所以一定会触发等待载入（实测即使只有 1 秒钟的音频，用 .play() 播放时也会先触发 onWaiting）。

而只要触发了 onWaiting 之后，onTimeUpdate 就失效了。但在这之后如果暂停一次再继续播放，onTimeUpdate 就能恢复正常。（微信团队真是懒政至极，这种 Bug 存在三年了，既不修复也不回复，真的好意思每个月继续领工资吗？😠）

二、解决问题

有人给的方案是用 setTimeout，原理就是运行 .play() 之后，等待一段时间让音频载入，然后运行一次暂停，然后再继续播放，就可使得 onTimeUpdate 正常运行。

但延时这个方案太丑陋了，长了影响体验，短了音频没载入完依然无效，永远不可能设置一个完美的延时长度。

对我这个场景而言（不需要拖动进度条），更理想的方式是点“重听”时，重新给 InnerAudioContext.src 赋值，并设置 InnerAudioContext.autoplay = true，它会等待音频载入完之后自动开始播放，不触发 innerAudioContext.onWaiting，所以 onTimeUpdate 也就能正常运行。

而如果你的场景需要支持用户手动调整进度（需要调用 innerAudioContext.seek），也别用延时的方案，在 innerAudioContext.onCanplay 里（代表这时已经载入完音频了），调用一次 .pause()，再调用一次 .play() 即可。