最可靠方式是用os/exec调用ffmpeg实现流式转码：设置cmd.Stdin为输入源、cmd.StdoutPipe()获取输出流、传参"-i" "-" "-f" "mp3"等明确格式、用cmd.Start()启动后实时读取，避免io.Copy阻塞，并配合context超时与goroutine安全清理。
如何用 os/exec 调用 ffmpeg 实现流式音频转码
Go 本身不内置音频编解码能力，直接用标准库无法解析或重编码音频帧。最可靠的方式是调用外部工具（如 ffmpeg），并通过管道实现流式处理——避免写临时文件、减少磁盘 IO 和延迟。
关键点在于：输入源（如 *os.File 或 io.Reader）要连到 ffmpeg 的 stdin，输出从 stdout 读取，同时必须显式设置 -i -（表示从 stdin 读输入）和 output.mp3（或 - 表示输出到 stdout）。
-
ffmpeg必须已安装且在$PATH中，否则exec.Command启动失败，错误信息为"exec: \"ffmpeg\": executable file not found in $PATH" - 务必设置
cmd.Stdin和cmd.Stdout，不能依赖cmd.Run()—— 它会阻塞直到进程结束，无法流式读取 - 常见错误：漏传
-f指定输入格式（如-f wav），导致ffmpeg无法自动探测，报错"Unable to find a suitable output format for 'pipe:'" - 若输入无格式头（如 raw PCM），必须加
-ar 44100 -ac 2 -f s16le等参数明确采样率、声道数、编码格式
cmd := exec.Command("ffmpeg", "-i", "-", "-f", "mp3", "-c:a", "libmp3lame", "-q:a", "4", "-")
cmd.Stdin = inputFile
cmd.Stdout = outputWriter
err := cmd.Start() // 不要用 Run()
if err != nil {
return err
}
// 后续需 wait + close，但可边写入边读取
为什么不能用 io.Copy 直接转发 ffmpeg 的 stdout
io.Copy 看似简洁，但它会等 ffmpeg 进程完全退出才返回，而实际音频转码可能持续数分钟，期间下游无法拿到任何数据——这违背“流处理”的本意。
真正流式处理需要：启动 cmd 后，立刻从 cmd.Stdout 创建一个 io.Reader，并由调用方按需读取（例如写入 HTTP 响应体、上传到对象存储、或喂给另一个处理器）。
立即学习“go语言免费学习笔记（深入）”；
- 必须用
cmd.StdoutPipe()获取读取器，而不是直接赋值cmd.Stdout为某个io.Writer -
cmd.Wait()必须在读取完成后调用，否则子进程僵尸化；若提前中断读取，需调用cmd.Process.Kill() - ffmpeg 输出可能带 stderr 日志（如进度、警告），若不读取会导致管道阻塞——建议用
cmd.Stderr = io.Discard或单独 goroutine 消费
如何安全地处理不同输入格式（MP3/WAV/FLAC）的自动探测与转码
用户上传的音频格式不确定时，硬编码 -f wav 会失败。ffmpeg 支持自动探测，但前提是输入有有效 header（如 WAV 头、ID3 标签），且必须通过 -i - 传递完整数据流——不能只传前几 KB。
更稳妥的做法是：先读取输入流前 1024 字节，用 mimetype 或 filetype 库粗略判断格式，再拼装对应 ffmpeg 参数；对无法识别的格式，fallback 到 -f mp3 或让 ffmpeg 自探（但需确保输入完整）。
- WAV 输入：通常无需指定
-f，但若含非标准 codec（如 GSM），需加-f wav+-codec:a copy避免重编码失败 - MP3 输入：
-f mp3可省略，但若含畸形 ID3v2，加-id3v2_version 3提高兼容性 - FLAC 输入：必须指定
-f flac，否则 ffmpeg 可能误判为 raw audio 并报错"Invalid data found when processing input" - 所有情况都建议加
-nostdin -y：禁用交互输入，强制覆盖输出
内存与并发控制：避免 goroutine 泄漏和 OOM
每个转码请求都启一个 ffmpeg 进程看似简单，但若并发量大（如 100+ 请求），会迅速耗尽系统资源：不仅 CPU/内存吃紧，还可能触发 ulimit 限制（如 open files）。
- 务必设置
cmd.SysProcAttr = &syscall.SysProcAttr{Setpgid: true}，便于后续用syscall.Kill(-pgid, syscall.SIGKILL)彻底清理子进程树 - 用
context.WithTimeout包裹整个流程，超时后主动 kill ffmpeg，防止卡死 - 不要把
cmd.StdoutPipe()返回的 reader 直接传给http.ResponseWriter而不做 buffer 控制——小块读写会放大 syscall 开销，建议用bufio.NewReaderSize(r, 64*1024) - 若需支持大量并发，应在上层做限流（如
semaphore），而非依赖 ffmpeg 自身队列
ffmpeg 的流式行为依赖输入是否 seekable，而 Go 的 io.Reader 大多不可 seek——只要参数正确、管道通畅，这点不影响转码，但会影响某些高级功能（如章节切分）。真正难的是错误传播：ffmpeg 出错时，stderr 可能滞后于 stdout 关闭，必须统一用 cmd.Wait() 获取最终 exit code，不能仅靠读取结果判断成功。
