RecorderManger录制时有小概率（但近期偏多）出现卡死的情况，为了排查，我们在录制相关的每一个地方都加了日志，下面是根据日志还原的一次问题现场： [图片] 上面提到的另一个录音丢失的帖子：https://developers.weixin.qq.com/community/develop/doc/000c88692982c858a41fddc0c5b800 ，这个当时比较容易复现。 小概率事件，没法提供可复现的代码片段。如有需要，我们可以让出现问题的用户配合提供微信日志。 2023-8-18 21:12 补充： 下面是小程序的日志，用户点击结束录音时，提示录音已经结束了，说明录音是自己提前异常结束的，在此之前小程序也没有收到过onError或者onStop回调。从分析的已录制时长52秒少于录制时长96秒也说明录音事实上早就结束了。用户提供的截图显示右上角是一个灰色的话筒，也说明了录音状态是异常的。 2023-8-18 20:32:35 [info] recorder.onStart 2023-8-18 20:34:11 [info] recorderManager.stop() called. 2023-8-18 20:34:11 [error] recorder.onError: {"errMsg":"operateRecorder:fail:audio is stop, don't stop record again"} 2023-8-18 20:34:11 [info] frameCount: 2025, estimated duration: 52.903124999999996s [图片]

[图片] 问题描述： 如图是我们自己的错误埋点，据埋点看，录音管理器RecorderManager调用pause时不稳定触发onError回调，异常信息:operateRecorder:fail:pause record fail，几乎同时又触发了一次onError回调，错误信息：audio is stop, don't stop record again， 此时录音管理器内部已经处于停止状态，但并未触发onStop回调（没看到埋点，验证了很多歌反馈都是这样），因此导致录音丢失。这个问题无法稳定复现，因此无法提供代码片段。但现在每天都有很多用户反馈，它们的系统、版本和基础库未观察到有明显规律。想知道为什么会触发这个异常因异常导致内部状态停止后，能否触发onStop希望官方能暴露内部状态给我们开发者想问一下除了通过onStop回调，还有什么方法能拿到录的音频文件的临时路径？有其他开发者遇到了这个问题吗?目前在社区好像没搜到还有另一个很奇怪的问题：调用RecorderManager.resume， 会触发两次onResume回调，排查发现并不一定会导致录音丢失，这个会有什么影响吗？