App端录音无法生成MP3因系统API不支持MP3编码，uni-app静默降级为aac/m4a；需原生转码或后端直接支持AAC格式。
uni-app 无法在 App 端（Android/iOS）直接录音生成 MP3 文件。调用 uni.getRecorderManager().start() 时设 format: 'mp3' 在微信小程序中有效，但在原生 App 环境下会被忽略——实际输出仍是 aac（Android）或 m4a（iOS），format 参数仅作兼容性占位，不触发真正编码转换。
为什么 App 端 start() 的 format: 'mp3' 不生效
App 端录音由系统原生 API（如 Android 的 MediaRecorder、iOS 的 AVAudioRecorder）驱动，它们原生不支持 MP3 编码（专利限制）。DCloud 封装层对 format 的处理是：遇到不支持格式时静默降级为默认格式（aac 或 m4a），不会报错，但也不会生成 MP3。
- 微信小程序：底层基于微信 SDK，
format: 'mp3'可用，且稳定 - H5 端：
MediaRecorder多数浏览器只支持webm或wav，mp3基本不可用 - App 端（uni-app 打包）：无论 manifest 配置或
start()参数怎么写，res.tempFilePath后缀都是.aac或.m4a
真要 MP3，必须转码 —— 但不能用前端 JS 库
想在 App 端拿到 MP3，唯一可靠路径是「原生转码」：把录音结束后的 aac 文件交给原生层，用 FFmpeg 或系统音频框架重编码。Web 端方案（如 ffmpeg.js、lamejs）在 App 环境下性能差、内存溢出风险高，且 iOS 上 WebAssembly 支持不稳定，不推荐。
- 推荐插件：
uni-plugin-audio-converter（已适配 Android/iOS，UTS 实现，轻量高效） - 替代方案：自己用 UTS 封装 FFmpeg for Android/iOS，控制输入/输出路径与参数
- 严禁操作：
fs.copyFile直接复制tempFilePath→ MP3 路径（源路径可能是content://URI，copyFile 不识别；且未转码，文件内容仍是 AAC）
保存前务必先 saveFile，再转码
onStop 回调里的 res.tempFilePath 是临时路径，重启或清理缓存后立即失效。必须先用 uni.saveFile 持久化，再传给转码插件：
manager.onStop((res) => {
uni.saveFile({
tempFilePath: res.tempFilePath,
success: (saveRes) => {
const savedPath = saveRes.savedFilePath;
// ✅ 此时 savedPath 是稳定路径，可安全传给转码插件
uni.convertAudio({
src: savedPath,
format: 'mp3',
success: (convRes) => {
console.log('MP3 已生成:', convRes.filePath); // .mp3 后缀
}
});
}
});
});
-
uni.saveFile会把文件移到uni.env.USER_DATA_PATH下，路径长期有效 - 转码插件的
src必须是savedFilePath，不是原始tempFilePath - 转码后务必校验：
uni.getFileInfo({filePath: convRes.filePath})确保 size > 0，避免空文件（常见于权限未真正就绪就调了start()）
更省事的方案：让后端支持 AAC
绝大多数语音识别（ASR）服务（如阿里云 ASR、讯飞开放平台、Azure Speech）都原生支持 aac（尤其是 ADTS 封装的 AAC-LC）。与其在前端费力转 MP3，不如确认服务端是否接受 aac：
- 检查文档是否列出
audio/aac或audio/mp4MIME 类型 - 上传时显式设置
header['Content-Type'] = 'audio/aac'（uni.uploadFile 中配置） - 若服务端返回
Unsupported audio format，再查它是否要求 MP3 的特定封装（如 ID3v2 header），而非单纯拒绝 AAC
绕过转码环节，能减少 300–800ms 延迟、避免 App 卡顿、杜绝因转码失败导致的录音丢失 —— 这才是多数项目该优先走的路。
