实现边生成边播放需采用流式TTS，通过WebSocket/SSE/分块传输实时推送音频流；文本需缓冲切分短句并归一化；前端用MediaSource动态拼接音频，辅以起音缓冲、淡入淡出及断连重连等优化。
要实现边生成文字边播放声音，关键在于打破“等全文生成完再合成”的旧模式，让文本片段一到达，语音就立刻开始输出。这依赖于流式TTS（Streaming TTS）的底层能力——不是处理整段文字，而是按 token 或短句粒度实时驱动声学模型，并通过低延迟通道把音频流持续推送给前端。
选择支持流式输出的TTS服务
并非所有TTS接口都支持真正流式。需确认服务是否提供以下任一能力：
- WebSocket 连接方式（如腾讯云 Streaming TTS、Azure Neural TTS 的 streaming endpoint）
- Server-Sent Events（SSE）响应头（Content-Type: text/event-stream）
- HTTP chunked transfer encoding + 持续写入音频二进制流（部分自建服务采用）
避开仅返回完整 WAV/MP3 文件的 REST API ——这类接口本质仍是批量模式，无法降低首包延迟。
文本分块与节奏控制
大模型输出是逐 token 流出的，但直接拿每个 token 去调用 TTS 效率极低且不自然。实际中需做轻量缓冲与语义切分：
- 在客户端或网关层缓存最近 200–500ms 的 token，凑成短句（如以逗号、顿号、句末标点为边界）
- 避免单字或过短词组触发合成（如“的”“了”“啊”单独合成会失真）
- 对数字、英文缩写等做简单归一化（如“2026年”→“二零二六年”），防止TTS引擎误读
示例逻辑：收到“今天天气很好”，可拆为 “今天” → “天气很好” 两段，中间留约 300ms 静音间隔，模拟真人呼吸停顿。
前端音频流拼接与无缝播放
浏览器不能直接播放未结束的音频流，需用 Web Audio API 或 MediaSource Extensions（MSE）管理：
- 使用 MediaSource 创建可动态追加的音频源，配合
audio/mpeg或audio/wav流格式 - 每收到一个音频片段（如 base64 或 ArrayBuffer），解码后追加到 sourceBuffer
- 监听
sourceopen和updateend事件，确保播放器自动衔接，不卡顿、不跳帧 - 若用 WebSocket 接收二进制音频块，建议统一为 16kHz 单声道 PCM，便于浏览器快速 decodeAudioData
容错与体验优化细节
真实场景中网络抖动、模型输出延迟、音频时长预估偏差都会影响体验：
- 预加载一个 200ms 空白音频 buffer，作为首段语音前的“起音缓冲”，掩盖首包延迟
- 当新音频块到达时，若当前正在播放，优先 fade-out 当前段最后 50ms，再淡入下一段，避免爆音
- 监听 WebSocket 的
onclose，自动重连并恢复上下文；对断连期间生成的文本做本地缓存重发 - 在 UI 上显示“正在说出…”状态，并同步高亮当前播报的文字位置（类似歌词滚动）
