Express.js 音频上传：搭建 AI 语音工作流底座

语音自动化落地时，最容易被低估的一步是：把音频可靠地送到你的后端。没有这一步，后面再高级的语音识别、摘要、工单分配、对话质检都只能停留在 Demo。

在“人工智能在物流与供应链”这条线上，这件事尤其关键。仓库现场的对讲录音、司机回传的语音回单、客服的电话录音、网点的语音留言……它们都是可自动化的高价值输入。现实是：很多团队在接入 AI 语音助手与自动化工作流时，会卡在文件上传、格式兼容、并发与存储策略这些“看起来不性感但很要命”的工程细节上。

这篇文章用一个可直接落地的方案，把浏览器端音频上传到 Express.js 服务端（用 Multer 处理 multipart/form-data）讲清楚，并进一步补齐你在生产环境里需要考虑的：命名策略、大小限制、校验、安全、与后续 AI 流程编排。

为什么物流与供应链的 AI 语音自动化离不开“上传层”

**答案：上传层决定了音频是否能稳定进入你的自动化流水线。**你可以把它理解成语音工作流的“进件口”。只要进件不稳，识别准确率再高也没用。

在物流场景里，音频进入系统通常来自 3 类入口：

1. 客服/坐席：电话录音或语音留言 → 自动转写 → 生成工单/回访任务
2. 司机/承运商：App 语音回传（异常说明、到货确认）→ 转写 → 触发理赔/重派/通知
3. 仓库/现场：语音盘点、对讲记录 → 转写 → 与 WMS/ERP 对齐，生成差异报告

这些入口共同点是：前端（Web/移动端）把音频以 multipart/form-data 发到后端。你需要一个可控、可扩展的 Express.js 上传接口，作为后续 AI 语音助手与自动化工作流（例如转写、摘要、情绪识别、分流）的基础设施。

服务端实现：Express + Multer，把音频接住并落盘

答案：用 Multer 作为 Express 中间件处理 multipart/form-data，并配置 diskStorage 把文件写入磁盘（或替换为对象存储）。

1) 最小可用的 Express 服务

const express = require('express')
const cors = require('cors')
const app = express()
const port = 8080

app.use(cors())

app.get('/', (req, res) => {
  res.json('Hello World')
})

app.listen(port, () => {
  console.log(`Example app listening at http://localhost:${port}`)
})

这段代码只负责“能跑”。但上传音频时，浏览器不会用 JSON 发文件，而是发 multipart/form-data。Express 默认不会帮你解析这种请求体，所以需要 Multer。

2) 配置 Multer 的 diskStorage

答案：显式设置 storage，否则 Multer 会把文件放内存，文件一大就顶不住。

const multer = require('multer')

const storage = multer.diskStorage({
  filename: function (req, file, cb) {
    cb(null, file.originalname)
  },
  destination: function (req, file, cb) {
    cb(null, './uploads')
  },
})

const upload = multer({ storage })

这能工作，但我建议你在物流/供应链场景里做两点增强：

• 避免文件名冲突：同名录音很常见（比如“recording.mp3”）
• 按业务维度分目录：按日期/网点/订单号分层，后续追溯更轻松

例如（示意思路）：

• 文件名：2026-02-12_order-893247_driver-1029_1707744302.webm
• 目录：uploads/2026/02/12/

3) 上传接口：POST /upload_files

答案：在路由上挂 Multer 中间件，字段名要和前端 input name 对上。

app.post('/upload_files', upload.any('file'), (req, res) => {
  res.send({ message: 'Successfully uploaded files' })
})

这里有个常见坑：

• 你在服务器写 upload.any('file')
• 你在表单里写 name="file"

两边必须一致，否则 Multer 找不到文件字段，上传就会失败。

生产建议：如果你只接收单文件，优先用 upload.single('file')，更清晰，也更易做校验。

前端两种上传方式：纯 HTML 表单 vs FormData

答案：能快速跑通用纯 HTML；要带业务字段（订单号、网点、工号）就用 FormData。

方式 A：纯 HTML 表单（最快验证链路）

<form enctype="multipart/form-data" action="http://localhost:8080/upload_files" method="POST">
  <label for="file-upload">Select file:</label>
  <input id="file-upload" type="file" name="file" />
  <input type="submit" value="POST to server" />
</form>

这适合你在开发期先确认：

• 服务端端口通不通
• uploads/ 是否落盘
• Multer 是否正确解析

方式 B：FormData（把音频变成“可自动化的业务事件”）

物流场景里，音频不是孤立的文件，它必须绑定上下文：订单号、运单号、异常类型、网点、司机 ID、语言等。这正是 FormData 的价值。

HTML：

<form>
  <label for="file">Select files</label>
  <input id="file" type="file" name="file" />
  <input type="submit" value="POST to server" />
</form>

JS（示意）：

const form = document.querySelector('form')
const fileInput = document.getElementById('file')
let file

fileInput.addEventListener('change', (e) => {
  file = e.target.files[0]
})

form.addEventListener('submit', (e) => {
  e.preventDefault()
  const formData = new FormData()

  // 业务字段：让音频能进入后续自动化
  formData.append('order_id', '893247')
  formData.append('site_id', 'SZ-WH-03')
  formData.append('event_type', 'delivery_exception')

  // 文件字段：注意字段名要与服务端一致
  formData.append('file', file)

  fetch('http://localhost:8080/upload_files', {
    method: 'POST',
    body: formData,
  })
})

这里我刻意把文件字段写成 file，因为你服务端最容易采用 upload.single('file') 这种明确约束。

生产环境必须补上的 5 件事（很多团队在这里翻车）

答案：限制、校验、命名、存储、异步化这五件事决定系统能不能扛住真实流量。

1) 限制上传大小与并发

语音留言可能只有 15 秒，但司机回传可能几分钟。你需要在 Multer 配置里加 limits，并在反向代理（如 Nginx）同步限制。

你可以制定一个清晰规则：

• 客服留言：≤ 10MB
• 司机异常说明：≤ 25MB
• 仓库对讲批量：走批处理通道，不走同一个接口

2) 校验 MIME 类型与扩展名

别只相信扩展名。最基本也要做：

• 允许：audio/wav、audio/mpeg、audio/webm、audio/ogg
• 拒绝：未知类型或可执行内容

这不只是安全问题，也是后续转写稳定性问题。

3) 文件命名策略：可追溯、可去重、可检索

我偏向用“业务可读 + 技术唯一”的组合：

• order_id / waybill_id
• actor_id（司机/坐席）
• 时间戳（秒级或毫秒级）
• 随机短串（防碰撞）

一句话：**让文件名本身就能当索引。**当你排查“某一单为什么没触发自动化”时，会省掉很多时间。

4) 磁盘只是起点：对象存储才是归宿

本地磁盘落盘适合开发与小规模试跑。只要进入正式环境，建议尽快迁到对象存储（S3/OSS/COS 等），原因很现实：

• 容器/实例扩容后，本地磁盘不共享
• 备份与生命周期管理困难
• 多区域/多网点访问延迟不可控

最常见的模式是：上传到 Express → 生成对象存储 Key → 异步上传 → 返回任务 ID。

5) 上传后不要同步转写：用队列拆开

如果你在 POST /upload_files 里直接调用转写并等待结果，接口会变慢且容易超时。更稳的做法：

1. 接收文件并落盘/入对象存储
2. 写一条“音频待处理”记录（含订单号等元数据）
3. 推送到队列（例如 Redis 队列/消息中间件）
4. Worker 异步做转写、摘要、分类
5. 回写结果到工单系统/ERP/WMS

这一步就是“自动化工作流”的核心：把音频上传变成可追踪的任务。

从“上传音频”到“AI 语音助手工作流”的最短路径

答案：上传接口只做两件事：接收 + 记录；智能处理交给异步流程。

给你一个物流小团队最容易落地的闭环示例（我见过很多公司用它在 2–4 周内跑通）：

• 司机在 App 上传语音：“客户拒收，外包装破损，已拍照。”
• Express 接收音频 + 元数据（运单号、司机 ID、异常类型）
• 后台异步转写
• 规则引擎识别关键词“拒收/破损”→ 自动创建异常工单
• 自动通知客服与仓库，并把转写文本写回运单备注

这套流程能直接减少人工听录音的时间，尤其在旺季（春节前后、618、双11、跨境清关高峰）更明显。

如果你正在做“AI 提升跨境物流效率”，语音上传同样是入口：把清关沟通、异常说明变成结构化文本，后续就能做多语种翻译、自动归因、合规审计。

一句话立场：别先追求“语音助手多聪明”，先把“音频怎么进系统”做扎实。

常见问题（团队最常问的几句）

Q1：为什么不能直接用 express.json() 接收音频？

因为音频是二进制数据，浏览器通常以 multipart/form-data 上传文件。express.json()只解析 JSON 文本，不解析 multipart。

Q2：用 upload.any() 还是 upload.single()？

能确定只有一个文件时，选 upload.single('file')。约束越清晰，校验越简单，故障越少。

Q3：上传成功后怎么把音频交给语音识别？

常用方式是：上传后拿到文件路径或对象存储 URL/Key → 写入队列任务 → Worker 调用语音识别服务处理 → 回写文本与结构化标签到你的业务系统。

下一步：把这个接口变成你的“语音自动化入口”

现在你已经有了一个能跑通的 Express.js 音频上传通道。把它放到“人工智能在物流与供应链”的体系里，它就是连接现场语音与自动化决策的桥。

我建议你接下来做三件事（按优先级）：

1. 加校验与限制：大小、类型、单文件字段名固定化
2. 加任务化：上传即创建任务，转写与分类异步执行
3. 加可观测性：每条音频从上传到转写完成要能追踪（任务 ID、状态、耗时、失败原因）

当你的系统能稳定吞下音频，下一次你再讨论“AI 语音助手能帮我们自动处理多少异常工单”，就不是概念，而是可量化的运营指标了。