uni.getRecorderManager()录音无响应需检查权限配置、初始化时机及平台差异：iOS需NSMicrophoneUsageDescription，Android需RECORD_AUDIO权限；必须onLoad后调用并主动授权；H5需用MediaRecorder；参数duration单位为毫秒，format推荐aac；tempFilePath需按平台处理路径；须监听onInterruptionBegin/End应对中断。
uni.getRecorderManager() 录音没反应？检查基础权限和初始化时机
uni-app 的录音功能依赖 uni.getRecorderManager()，但它本身不触发任何行为——你得手动调用 start()，且必须确保用户已授权录音权限。iOS 和 Android 行为差异大：iOS 要求在 manifest.json 里配置 NSMicrophoneUsageDescription，Android 则需在 permissions 中声明 android.permission.RECORD_AUDIO；未配置时，start() 会静默失败，控制台也不报错。
常见错误现象：onStart 不触发、onError 也收不到回调、getRecorderManager() 返回对象看似正常但完全无响应。
- 务必在
onLoad或用户点击按钮后才调用uni.getRecorderManager()，不要在data或created钩子中提前初始化（某些平台下 manager 实例不可用） - 调用
start()前，先用uni.authorize({scope: 'scope.record'})主动申请权限，别依赖自动弹窗（H5 不支持该 API，需降级处理） - H5 端无法使用此 API，必须用
MediaRecorder替代，且仅限 HTTPS 环境；开发时容易误以为“写了就跑通”，上线后发现白屏或静音
录音参数 duration 和 format 怎么设才不踩坑
duration 是毫秒单位，不是秒——设成 60 就是录 60 毫秒，根本来不及反应；format 决定输出格式，但不同端支持程度天差地别：mp3 在 iOS 微信内嵌 WebView 中基本不可用，aac 是最稳妥选择，Android 和 iOS 均原生支持，H5 则只认 webm 或 ogg（还得看浏览器）。
性能影响明显：format: 'wav' 体积爆炸（1 秒 ≈ 170KB），上传慢、解码卡，纯属自找麻烦；sampleRate 设太高（如 44100）在低端安卓机上容易触发 onError 并返回 recorder error: 1002（硬件不支持）。
- 推荐配置：
{ duration: 60000, format: 'aac', sampleRate: 16000, numberOfChannels: 1, encodeBitRate: 48000 } - 微信小程序要求
duration必须 ≤ 60000，超时会自动停止，且不会触发onStop，只能靠onInterruptionBegin监听异常中断 - 真机调试时，用
adb logcat或 Xcode 控制台看底层报错，比 uni-app 的onError更早暴露问题
onStop 拿不到 tempFilePath？路径权限和生命周期是关键
录音结束后的 tempFilePath 是临时路径，只在本次小程序/应用生命周期内有效。iOS 下该路径形如 file:///var/mobile/Containers/Data/Application/xxx/tmp/xxx.m4a，不能直接传给 uni.uploadFile——后者只接受 http://、https:// 或 本地相对路径（如 tmp_abc.m4a），而 file:// 协议会被拒绝。
常见错误现象：打印 res.tempFilePath 看起来正常，但 uni.uploadFile 报错 uploadFile:fail invalid file path；或者 H5 端拿到的是 Blob 对象，不是路径字符串。
- Android 和 iOS 必须用
uni.saveFile({ tempFilePath })先转成持久路径，再上传；注意saveFile成功后返回的savedFilePath才能用于上传 - 微信小程序可跳过
saveFile，直接用tempFilePath上传，但需确保没有跨页面跳转——页面卸载后临时文件被清空，tempFilePath失效 - uni-app 的
tempFilePath在 H5 端实际是BlobURL（blob:http://xxx），上传前得用URL.createObjectURL(blob)转换，或改用FormData直接提交Blob
录音中途被电话/闹钟打断？onInterruptionBegin 和 onInterruptionEnd 必须监听
移动端录音极其脆弱：来电、微信语音通话、系统闹钟、甚至某些国产手机的“省电模式”都会强制中断录音，且不会触发 onStop。如果不监听中断事件，用户可能以为还在录，实际已停，最后上传空文件或旧文件。
iOS 和部分安卓厂商（如华为 EMUI）对后台音频限制极严，录音时切到后台 1–2 秒就会被系统终止；微信小程序在前台时也可能因其他小程序抢占音频资源而中断。
- 必须在获取
manager后立即绑定：manager.onInterruptionBegin(() => { console.log('录音被中断'); }) -
onInterruptionEnd不代表能自动恢复录音——它只是通知“中断结束了”，你还得手动调用start()，并重置计时器、UI 状态等 - 真机测试时，用另一台手机打自己号码，比模拟器更真实；别只测“点开始→点停止”这种理想流
录音不是调个 API 就完事，从权限、格式、路径到中断恢复，每一步都有平台特异性。最容易被忽略的是：你以为的“一次调用”在不同端其实是三套实现逻辑，混在一起写，上线就出声儿——没声儿。
