流式TTS接口选型：WebSocket为何比SSE更适合实时语音合成？

接手流式 TTS 接口选型的时候，很多朋友的第一反应是“服务端要持续往客户端推音频，那用 SSE 不就行了？又简单又是浏览器原生支持”。这个思路在纸面上确实成立，但真把音频数据放进去跑一轮原形，你会发现坑一个接一个：编码、鉴权、打断、重连、语义边界，全都绕不过去。我现在的结论很明确：生产级流式 TTS，WebSocket 在绝大多数情况下都比 SSE 合适，而且这不是口味问题，是协议能力决定的。

今天这篇就把这背后的逻辑完整拆一遍。我会从二进制帧、签名鉴权、双向控制三个角度讲清楚 WebSocket 相对于 SSE 的优势，然后给出一套可以直接落地的连接设计、消息格式、鉴权流程和排障手册。正在做语音合成接口、或是在 SSE 和 WebSocket 之间纠结的朋友，可以把它当成一份工程参考来读。先说明白一个前提：我这里聊的流式 TTS，指的是文本输入后流式输出音频片段的实时合成接口，交互上要求低延迟、可打断、偶尔要动态调整参数，这跟单纯用 SSE 做消息推送完全是两类需求。理解了这个前提，后面所有技术选择就都顺理成章了。

1. 表面看都是“持续推送”，底层设计假设完全不同

很多人把 SSE 和 WebSocket 混为一谈，因为从应用层看，两者都能做到“服务端主动往客户端推数据”。但从协议设计初衷上讲，它们是两条完全不同的路，这直接决定了它们适合承载什么类型的数据。

1.1 SSE 的设计假设是“单向文本推送”

SSE 全称 Server-Sent Events，它本质上是 HTTP 协议的扩展：客户端用 EventSource 接口发起一个请求，服务端不结束响应，而是以text/event-stream的格式持续往下写事件。每个事件以data:开头，以空行分隔，默认是 UTF-8 文本。

这个设计有一个很明确的假设：数据是从服务端流向客户端的、文本型的事件通知。典型场景是行情推送、站内通知、任务进度提醒。因为基于 HTTP，它天然享受 HTTP 层的各种设施：负载均衡、代理、缓存、防火墙都能直接透传，部署成本低。但它同时也继承了 HTTP 的几个限制：

• 单向：客户端只能用 HTTP 请求“发起”，连接建立后很难再向服务端主动发数据。
• 文本：协议层面的数据单元是文本行，没有二进制帧的概念，传二进制需要先编码成文本。
• 连接生命周期：事件流一旦中断，重连要靠 EventSource 自带的retry机制，服务端只能通过发心跳维持。

这些限制放在 TTS 场景里就是致命的。合成出来的音频是 PCM、Opus、MP3 这类二进制字节流，用文本通道传输等于给数据额外套一层枷锁。

1.2 WebSocket 的设计假设是“全双工 + 二进制”

WebSocket 走的是另一套设计路线，它有独立的帧协议，握手阶段通过 HTTP Upgrade 建立连接，之后数据交互不再遵循 HTTP 语义，而是走自己的帧格式。RFC 6455 定义了两种最重要的帧：文本帧和二进制帧。

这种设计带来的能力差异非常具体：

• 全双工：客户端和服务端可以在同一个连接上随时互发数据，不需要重新建立连接。
• 二进制帧：音频数据可以以原始字节形式传输，不需要编码成文本。
• 独立帧协议：每个帧有明确的 opcode、长度边界，应用层可以基于帧做消息分割，不存在 SSE 那种“靠空行切文本块”的限制。

换句话说，WebSocket 从设计之初就是为“低延迟、高频、双向、多类型数据”的应用准备的。实时语音、实时视频、在线协同、游戏同步，这些场景里它都是事实标准。

1.3 对 TTS 来说，这些差异不是小优化，而是决定性问题

我做流式 TTS 接口的协议设计时，最终没有选 SSE，核心原因归纳起来就三点：

1. 音频负载必须用二进制帧承载，文本通道的编码开销无法接受。
2. 实时合成要求客户端能随时发出控制指令，SSE 在这个场景下没有可用的“上行通道”。
3. 鉴权和连接管理在长连接场景下有特殊要求，WebSocket 的握手流程更容易做签名鉴权。

这三个问题下文逐一展开，每一节我会结合真实的工程细节讲清楚。

2. 二进制帧：流式音频传输效率的关键胜负手

2.1 音频数据本来就是字节流，不需要也无必要转成文本

先说一个最简单的事实：TTS 引擎合成的原始音频，在多数场景下是 16-bit 线性 PCM，采样率 16000 或 24000，单声道或双声道。这个数据在内存里就是连续的二字节整数序列。把它交给网络层传输，最合理的方式就是直接作为二进制字节块发出去。

如果你用 SSE，就必须要先做一步转换，最常见的是 Base64 编码。Base64 会把每 3 个字节编码成 4 个 ASCII 字符，传输体积直接膨胀约 33%。这不是一个小数字。

算一笔账：一段 10 分钟的 16kHz 单声道 16-bit PCM 音频，原始数据量大概是16000 × 2 × 600 = 19.2 MB。Base64 编码后，大约变成 25.6 MB。多出来的 6.4 MB，在网络带宽上就是多付的份子钱，尤其是在移动网络、弱网环境下，这部分额外开销会被放大三倍五倍感知到。

2.2 Base64 的开销不只是体积膨胀，还有 CPU 和延迟

很多人的直觉是“带宽不够就加带宽，反正现在网络快了”。但实际做流式接口，Base64 的开销远不止网络层这一点。

• 服务端编码：每一帧音频从 PCM 字节流转成 Base64 字符串，需要一个 Base64 编码器，每秒合成的数据量越大，编码器消耗的 CPU 就越明显。
• 客户端解码：客户端收到 Base64 字符串后，要先解码回字节数组才能交给音频播放器。解码同样是 CPU 和内存分配开销。
• 缓冲延迟：为了做 Base64 编码，服务端往往需要将音频数据收集到一定大小才能高效编码，这直接增加了首包延迟。

在按边合成边传输的 TTS 场景里，每一毫秒延迟用户都能感受得到。Base64 这套附加的编解码链条，纯粹是不必要的中间环节。

2.3 用 WebSocket 二进制帧承载音频的设计模式

改用 WebSocket 之后，音频数据的处理就干净多了。服务端直接 write 一段音频字节，客户端收帧后直接丢给解码器/播放器。

实际项目中我常用的二进制消息结构大概是这样的：

// 二进制帧 payload 结构示例 // [0-1] 消息类型 (uint16) // [2-3] 采样率 (uint16) // [4-5] 通道数 (uint8) // [6-7] 编码格式 (uint8, 0=PCM, 1=Opus, 2=MP3) // [8-N] 音频数据

帧的前 8 个字节是头信息，后面的字节直接是音频负载。客户端解析的时候：

socket.binaryType = 'arraybuffer'; socket.onmessage = (event) => { if (typeof event.data === 'string') { // 处理 JSON 控制消息 handleControlMessage(JSON.parse(event.data)); } else { const bytes = new Uint8Array(event.data); const sampleRate = (bytes[2] << 8) | bytes[3]; const channels = bytes[4]; const audioData = bytes.subarray(8); // 交给播放器或解码器 playAudio(audioData, sampleRate, channels); } };

注意这里的关键点：binaryType必须设置为'arraybuffer'，否则浏览器默认会按'blob'类型接收。还有个容易踩的坑是：不要用typeof判断字符串以外的类型时误判，取到 ArrayBuffer 之后再转换成 Uint8Array 操作，避免每个字节都走一次 JavaScript 数组的越界检查。

2.4 帧边界带来的附加优势：天然的消息分段能力

做流式协议设计时，一个最容易被忽略的好处是 WebSocket 帧自带长度边界。每个帧到达时，应用层可以直接拿到一个完整的消息，不需要自己处理“半包”和“粘包”问题。

用 SSE 做流式输出时，数据是以文本流形式到达的，事件边界靠空行分隔。客户端需要按照data:前缀解析、用空行切分事件，如果音频数据做了 Base64，还要在解码时处理“Base64 字符串被截断在中间”的各种边界情况。WebSocket 的事件回调本身就是按帧触发的，客户端的 onmessage 拿到的就是服务端发送的一整条帧，解析过程简单得多。

3. 签名鉴权：长连接场景下的安全设计与实践

3.1 WebSocket 握手本质上是 HTTP 请求，鉴权机会就在这里

很多人误以为 WebSocket 的鉴权很难做，其实恰恰相反。WebSocket 的握手过程是这样的：

客户端发起 HTTP GET /path 请求头中包含: Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: xxx Sec-WebSocket-Version: 13

服务端验证请求、返回 101 状态码后，连接才升级为 WebSocket。这个握手请求本质上就是一个 HTTP 请求，所以你可以用任何 HTTP 鉴权方案来保护握手入口：Header、Cookie、Query 参数，都可以。

精度上来说，无论是 Header 还是 Query 参数，最稳妥的做法是引入签名机制，而不是用明文 token。明文 token 一旦在日志里泄露，攻击者可以直接重放。

3.2 签名鉴权流程：时间戳 + 随机数 + HMAC 签名

我这里给一套在流式 TTS 接口里验证过的签名方案，不需要引入额外的鉴权服务，只需要客户端和服务端共享一个密钥：

签名串构造规则： signString = appid + "\n" + timestamp + "\n" + random 签名结果： signature = HMAC-SHA256(secretKey, signString) 最终握手 URL： wss://api.example.com/tts/stream?appid=xxx&ts=1700000000&rd=abc123&sign=base64url(signature)

服务端校验流程：

1. 取出appid，查表拿到该应用对应的secretKey。
2. 用同样的规则本地重新计算signature。
3. 使用常量时间比较或标准的哈希比较函数，防止时序攻击。
4. 校验timestamp是否在 5 分钟内，过期的签名直接拒绝，避免重放攻击。

这里有一个细节很关键：签名字符串的拼接方式必须和服务端完全一致，包括换行符。我在实际排障中遇到过好几次握手 401，最后发现是客户端用\n换行拼接，而服务端规范文档里写的是\n，但两端语言实现的字面量不一致，导致签名结果始终对不上。类似这种问题，最直接的办法是写一个两端共用的签名生成测试用例，或至少把样例签名跑通再上线。

3.3 浏览器限制下，如何优雅地传递鉴权信息

浏览器环境里的 WebSocket API 有个历史限制：new WebSocket(url)不能自定义Authorization请求头。如果你把签名放在 Header 里，浏览器客户端根本发不出去，只有在 Node.js 或小程序等非浏览器环境才能用自定义 Header 的方式。

所以面向浏览器的接口，签名信息一般放在 URL 参数里。这里要注意两个安全点：

• URL 会出现在访问日志、代理日志中，所以签名参数不要明文透传核心 token，要用 HMAC 签名后的结果。
• 签名中的timestamp过期时间要设置得足够短，建议 2~5 分钟，过期后客户端就必须重新获取签名才能建立长连接。

如果你做的是服务端到服务端的集成，那可以直接使用自定义 Header：

Authorization: Bearer <token>

或者证书双向认证方案。这部分跟 HTTP 接口的鉴权套路完全一致，不需要额外设计。

3.4 SSE 鉴权的尴尬之处：上行通道缺失导致鉴权流程残缺

很多想用 SSE 做 TTS 的人，会在鉴权这一步发现一个麻烦：EventSource同样不能设置自定义 Header，鉴权信息也只能放在 URL 参数里。这个问题和 WebSocket 是一样的。

但更麻烦的是后续，如果服务端希望在连接过程中做二次校验、踢掉某个设备、更新权限，SSE 这边没有任何机制。WebSocket 则可以在连接建立后，随时通过发一个 JSON 控制消息或直接关闭连接来终止会话。

所以说，SSE 并不是“不能做鉴权”，而是“只能做一次性握手校验”，后续的生命周期管理能力非常弱。对生产级接口来说，连接建立后的鉴权复核、会话管理、主动失效这些需求几乎是标配，这些在 WebSocket 里都能轻松实现。

4. 双向控制：流式 TTS 的真正刚需

4.1 “合成一段文本”不是一次即发即忘的操作

如果你把 TTS 理解成“客户端发来文本，服务端返回音频”，那确实用一个单向通道就够了。但实际流式合成产品里，用户操作是动态的：想喘气、想暂停、想重新读一遍某句话、想让某个语气词更重、想快速切换音色——客户端必须能把这些指令在合成过程中实时传给服务端。

举几个最常见的控制需求：

• 打断：用户输入了一段话，还没播完，用户又说了新的内容，此时需要立刻停止当前合成，丢弃已生成的音频，开始新文本。
• 暂停/恢复：朗读过程中用户可以暂停，暂停不能影响服务端已经生成的数据，恢复后要能接着播放。
• 动态参数调整：语速、音量、音色风格，在合成进行中动态切换。
• 心跳保活：长时间空闲时，客户端需要定期发一个 ping 或心跳消息，告诉服务端连接还活着。

这些需求要求一个稳定的上行通道，而 SSE 恰恰没有这个东西。

4.2 用 WebSocket 设计一个控制通道与数据通道分离的协议

WebSocket 是双向的，所以我们可以在一个连接里同时跑两条逻辑通道。最直接的方式是用不同的消息类型区分控制消息和音频数据。我一般用这样的方式：

// 客户端发送控制消息 socket.send(JSON.stringify({ type: 'start', text: '欢迎大家体验流式语音合成接口', voice: 'zh-CN-XiaoxiaoNeural', rate: '1.0', volume: '100' })); socket.send(JSON.stringify({ type: 'append_text', text: '，这是后续追加的文本内容' })); socket.send(JSON.stringify({ type: 'stop', request_id: 'uuid-xxx' }));

服务端发送两种消息：

// 控制消息，文本帧 socket.send(JSON.stringify({ type: 'sentence_start', sentence_id: 1, text: '第一句话' })); // 音频数据，二进制帧 socket.send(audioBinary);

用文本帧做控制、二进制帧做音频，通过 opcode 区分，客户端在 onmessage 里先看类型再决定是解析 JSON 还是解码音频。这个模式的好处是：

• 控制信息易于调试，浏览器控制台可以直接看文本帧。
• 音频数据零编码开销，直接喂给解码器。
• 两类消息互不干扰，语义清晰。

4.3 如果非要用 SSE，双向控制要怎么做

话说回来，SSE 也不是完全做不了控制。一个常见的变通方案是：客户端通过一个独立的 HTTP POST 接口发送控制指令，服务端根据 request_id 找到对应的 SSE 连接，在流里注入终止数据或修改参数。但这会带来几个工程问题：

• 需要维护“控制请求 -> 活动连接”的关联表，分布式部署下还要引入会话存储或集中式状态。
• 控制指令和音频流是两个不同的连接，难以保证严格的时序和一致性。
• 服务端要管理额外的 HTTP 连接，连接生命周期更复杂。

相比之下，一个 WebSocket 连接把所有事情都包了。控制消息和音频数据走同一条 TCP 连接，天然有序，不会出现“我发了停止指令，服务端还在推旧音频”的错乱感。

5. 实操：搭建一个流式 TTS WebSocket 接口

5.1 协议设计文档先行

做这类实时接口，强烈建议先写协议文档，把消息类型、字段、流程确定下来，再动代码。一套可参考的最小协议设计如下：

连接：wss://api.example.com/tts/stream?sign=...&ts=...&appid=... 客户端 -> 服务端: - start {type:"start", request_id, text, voice, format, sample_rate} - stop {type:"stop", request_id} - heartbeat {type:"ping"} 服务端 -> 客户端: - ready {type:"ready", request_id, format, sample_rate} - sentence_start {type:"sentence_start", sentence_id, text} - audio 二进制帧，header + pcm/opus 数据 - sentence_end {type:"sentence_end", sentence_id, duration_ms} - finish {type:"finish", request_id, total_duration_ms} - error {type:"error", code, message}

start消息由客户端发出，服务端收到后返回ready，确认合成参数，然后开始流式返回音频。整个生命周期只有这一个双向握手的成本。

5.2 客户端连接与鉴权示例

下面给出一个 Node.js 客户端的完整示例，你可以直接用：

const crypto = require('crypto'); const WebSocket = require('ws'); const appid = 'your_app_id'; const secretKey = 'your_secret_key'; function buildSign() { const ts = Math.floor(Date.now() / 1000); const rd = crypto.randomBytes(8).toString('hex'); const signString = `${appid}\n${ts}\n${rd}`; const sign = crypto.createHmac('sha256', secretKey) .update(signString) .digest('base64url'); return { ts, rd, sign }; } async function connectTTS(text) { const { ts, rd, sign } = buildSign(); const url = `wss://api.example.com/tts/stream?appid=${appid}&ts=${ts}&rd=${rd}&sign=${sign}`; const ws = new WebSocket(url); ws.binaryType = 'arraybuffer'; // 连接成功后发送开始合成消息 ws.on('open', () => { ws.send(JSON.stringify({ type: 'start', request_id: crypto.randomUUID(), text, voice: 'zh-CN-XiaoxiaoNeural', format: 'pcm', sample_rate: 24000 })); }); ws.on('message', (data, isBinary) => { if (!isBinary) { const msg = JSON.parse(data.toString()); if (msg.type === 'sentence_start') { console.log(`开始合成第 ${msg.sentence_id} 句`); } else if (msg.type === 'finish') { console.log('合成完成'); ws.close(); } else if (msg.type === 'error') { console.error('出错:', msg.code, msg.message); ws.close(); } return; } // 处理二进制音频帧 const bytes = new Uint8Array(data); const sampleRate = (bytes[2] << 8) | bytes[3]; const channels = bytes[4]; const audioData = bytes.subarray(8); // 这里将 audioData 推给播放器 console.log(`收到音频帧: ${audioData.byteLength} 字节, ${sampleRate}Hz, ${channels}ch`); }); ws.on('close', (code, reason) => { console.log(`连接关闭: ${code} ${reason}`); }); ws.on('error', (err) => { console.error('WebSocket 错误:', err); }); return ws; }

注意几个容易犯错的地方：

• 签名里的timestamp必须用服务端时间的秒级时间戳，别用毫秒。
• base64url编码和标准 Base64 有区别，URL 里+和/要换成-和_，去掉末尾的=。
• 服务端如果对request_id做幂等处理，客户端重连时不建议换新的request_id，用同一个更容易排查问题。

5.3 服务端实现要点

服务端我用一个简单例子说明核心逻辑，这里以ws库为例：

const WebSocket = require('ws'); const crypto = require('crypto'); const wss = new WebSocket.Server({ port: 8080 }); wss.on('connection', (ws, req) => { // 解析握手 URL 中的签名参数 const url = new URL(req.url, 'http://localhost'); const appid = url.searchParams.get('appid'); const ts = url.searchParams.get('ts'); const rd = url.searchParams.get('rd'); const sign = url.searchParams.get('sign'); // 校验签名 const secretKey = getSecretByAppId(appid); const signString = `${appid}\n${ts}\n${rd}`; const expectSign = crypto.createHmac('sha256', secretKey) .update(signString) .digest('base64url'); // 防止时序攻击 const ok = crypto.timingSafeEqual(Buffer.from(sign), Buffer.from(expectSign)); if (!ok) { ws.close(4001, 'signature mismatch'); return; } ws.on('message', (data, isBinary) => { if (!isBinary) { handleControl(JSON.parse(data.toString()), ws); } else { // 实际场景下客户端很少发二进制帧，一般只用于数据上传 } }); }); function handleControl(msg, ws) { if (msg.type === 'start') { const audioStream = startTTS(msg); audioStream.on('data', (audioChunk, meta) => { // 发送控制消息 if (meta.sentenceStart) { ws.send(JSON.stringify({ type: 'sentence_start', sentence_id: meta.sentenceId, text: meta.text })); } // 发送二进制音频帧 const header = Buffer.alloc(8); header.writeUInt16BE(0x01, 0); // 音频消息类型 header.writeUInt16BE(msg.sample_rate, 2); header.writeUInt8(1, 4); // 单声道 header.writeUInt8(0, 5); // PCM 格式 const payload = Buffer.concat([header, audioChunk]); ws.send(payload); }); audioStream.on('end', () => { ws.send(JSON.stringify({ type: 'finish', request_id: msg.request_id, total_duration_ms: 2830 })); }); } else if (msg.type === 'stop') { // 终止当前合成，清空缓冲 ws.send(JSON.stringify({ type: 'finish', request_id: msg.request_id, interrupted: true })); } else if (msg.type === 'ping') { ws.send(JSON.stringify({ type: 'pong' })); } }

真实生产环境里，服务端还需要处理：多实例部署时的高可用、音频合成进程的隔离、鉴权密钥的轮换、日志采样的脱敏等，这些就超出协议设计本身了，但都属于上线前必须想清楚的事。

5.4 延迟预算：为什么减少中间环节就等于提升用户体验

流式 TTS 的体验和质量是直接挂钩的。所谓“流式”，一个很重要的指标是首句延迟：从用户点击播放，到第一段音频真正进入扬声器，这个时间越短，用户越感觉不到“机器在思考”。

我的典型延迟预算大概是这样的：

• 网络握手：50~200 ms
• 服务端合成第一个音频块：200~500 ms
• 音频传输：取决于块大小，通常 100~300 ms
• 客户端解码+播放：20~50 ms

如果用 SSE + Base64，客户端还需要至少一个额外的解码步骤和边界拼接过程，这一下就能增加 100~200 ms 的延迟。而 WebSocket 二进制帧直接把每个音频块作为独立事件交付给客户端，客户端可以直接解码播放，省下的时间都是实打实的体验提升。

6. 常见问题与排查技巧实录

6.1 WebSocket 连接秒断，状态码 1006

状态码 1006 表示连接异常关闭，没有收到正常的 close 帧。这个情况在调试过程中出现频率极高，大多数根因是代理层不支持 WebSocket 协议升级，或代理层主动断开了空闲连接。

实践中我常用的排查顺序：

• 用wscat或自写脚本先直连服务端，排除客户端问题。
• 检查 Nginx 配置，是否设置了proxy_read_timeout和proxy_send_timeout太短。
• 检查代理层是否缓冲了 101 响应。
• 查看服务端日志，确认是握手阶段被拒，还是连接建立后被主动 kill。

Nginx 参考配置片段：

location /tts/stream { proxy_pass http://backend; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_read_timeout 3600s; proxy_send_timeout 3600s; }

这个配置里最容易漏的就是proxy_set_header Connection "upgrade"，少了这一行，Upgrade 请求头到不了后端。

6.2 签名校验一直失败，但服务端日志里看不到拒绝详情

这种情况下先用固定样本自测：

• 确认两端时间戳一致，如果服务端和客户端差超过 5 分钟，签名直接过期。
• 确认拼接字符串中的换行符确实是\n，别用\r\n。
• 确认base64url编码没有填+/和=。
• 在服务端打印接收到的原始 URL 参数，确认没有 URL 转义变化，比如空格被转成%20、中文被转成百分号编码。

一个很刁钻的坑：某些网关层在转发请求时会把整个 URL 重新编码，如果签名的原串里包含非 ASCII 字符，签名结果在转发前后可能不一致。所以我的建议是签名字符串里尽量只用 ASCII 安全字符，appid 用纯数字或字母，rd 用 hex，ts 用纯数字。

6.3 音频数据解码出来全是噪声或速度不对

这种情况基本可以锁定是参数错位或状态机没对齐：

• 检查 sample_rate、channels、bit_depth 是否匹配，客户端播放器设置不对，采样率差一点，声音就全变味。
• 检查消息帧头里写入的采样率是否和服务端实际合成采样率一致。
• 检查有没有把控制帧当音频帧解析，或者 text 帧和二进制帧混在一起处理。

我用过一个傻瓜式排查法：先把收到的音频块写进本地文件，文件头加上 PCM/WAV 头后，用本地播放器直接播。如果本地能播、线上不能播，说明问题在播放链路；如果本地播不了，说明服务端发出来的数据本身就残了。

6.4 长连接在空闲一段时间后被服务端断开

TTS 会话很多时候会有空闲期，比如用户暂停了一会儿再继续。这时候如果服务端因为心跳超时断开连接，客户端需要能够自动重连。

根治办法是客户端定期发心跳：

setInterval(() => { if (ws.readyState === WebSocket.OPEN) { ws.send(JSON.stringify({ type: 'ping' })); } }, 15000);

服务端可以根据ping消息刷新最后活跃时间，超时 60 秒未收到任何消息再断开。心跳间隔建议设置为超时时间的三分之一到一半，避免频繁心跳和超时之间产生竞态。

6.5 服务端明明发了音频，客户端却迟迟不播放

排查顺序：

• 先看二进制帧是否真的到达了 onmessage，在回调里打日志。
• 看播放器缓冲逻辑，是不是累积到足够的音频才开始播，如果是，设置过大的缓冲阈值会明显增加首包延迟。
• 看浏览器音频上下文是暂停态还是运行态，很多浏览器要求用户交互后才能启动 AudioContext。
• 注意数据量如果太大，一次性全塞给播放器可能导致丢帧，建议用队列配合定时器消费。

另外还有一个体验细节：播放器在首包到达前，最好先用采样率信息初始化 AudioContext，不然再重新初始化时会产生明显的启动间隙。

7. 最后说几句我的个人体会

从第一次用 SSE 做了 TTS Demo 被延迟和断流折磨，到后来全面切到 WebSocket 把协议梳理干净，这个过程让我对“协议选型”这件事有了很具体的认知。很多技术选型问题，看着像是个人偏好，实际上背后全是数据格式、交互模式、生命周期管理的硬约束。TTS 的音频负载偏二进制，交互模式偏双向，连接生命周期偏长，这三点同时出现，SSE 就已经出局了。

如果你正在做类似接口，我建议你动手前先画一张数据流图，把每一个消息对应的方向画出来。只要这个图里有任何一条从客户端指向服务端的线，SSE 就不该是你的默认选项。而如果服务端的推送里有任何一块二进制数据，SSE 就几乎可以直接放弃。反过来，如果你只是做一个服务端往客户端推文本通知的场景，那真不必引入 WebSocket，SSE 会更轻，部署也更省事。

最后再分享一个小技巧：流式接口上线前，一定要做一次断网恢复测试。把客户端连上之后，人为关掉网络几秒钟再恢复，观察重连逻辑是否能正确续传，签名是否会失效，数据库记录会不会出现重复的 request_id。这类细节在实际业务里远比协议本身更容易出事故。把这些坑跨过去，你的流式 TTS 接口才真正有资格说一句能上生产。