刚开始想得特别简单，觉得不就是把SoX塞进容器嘛。Dockerfile第一版长这样：
跑起来才发现问题大了------处理完的音频文件都困在容器里，根本拿不出来。这才想起容器内外的文件系统是隔离的。解决办法倒是简单，用数据卷挂载就行：
这样把宿主机的input和output目录挂载进去，容器就能直接读写本地文件了。
接着遇到第二个坑：音频处理需要实时交互时，容器默认没有音频设备。查了文档发现需要加上设备挂载参数：
不过对批量处理来说，更实用的还是准备个配置文件。比如把降噪参数写成noise.prof放在挂载目录里，这样不同环境都能复用同一套配置。
实际测试时又发现性能问题。刚开始容器只分配了1核CPU，处理大文件慢得让人抓狂。后来加上资源限制参数就好多了：
现在我的工作流已经固定下来了：本地放好待处理音频→执行打包好的Docker命令→从output目录取结果。最近还把处理脚本封装成了docker-compose.yml：
最爽的是把镜像推送到仓库后，团队里其他人不用再折腾SoX安装，直接拉取镜像就能跑。有次在CI流水线里集成了这个镜像，半夜自动处理新增的音频文件，第二天早上直接看结果就行。
另外还踩过时区的坑。因为音频文件元数据里的时间戳总是差8小时，最后在Dockerfile里加了这句：
现在想想，用Docker做音频处理最香的不是技术多先进，而是消除了环境差异。以前新人来都要配半天环境，现在只需要装个Docker，五分钟就能开始干活。而且处理流程标准化之后，再也没出现过"在我机器上好好的"这种经典问题。
如果非要挑缺点，可能就是镜像体积有点大。Ubuntu基础镜像加上SoX之后接近300MB，后来换alpine基础镜像才压到50MB以内。不过对现在动辄几个G的音频素材来说，这点镜像体积真不算什么。
最近在研究把FFmpeg也打包进去，准备搞个全能型音频处理镜像。到时候什么格式转换、采样率调整、声道合并，一个容器全搞定。有同样需求的同学不妨试试这个方案，真的能省不少事。