通义千问 SSE 流式：累计文本 vs 增量 Delta

一个 bug 牵出的问题

前端流式对话时发现通义千问返回的内容重复：

你好！你好，不过，有什么有什么我可以帮助你的吗？

至于排查发现，通义千问每条 SSE 事件的 output.text 是完整文本不是增量。

// event {"output":{"text":"你好"}}
// event {"output":{"text":"你好！"}}
// event {"output":{"text":"你好！有什么"}}

而 OpenAI 系列返回的是增量 delta：

// event {"choices":}
// event {"choices":}
// event {"choices":}

如果后端把通义千问的每条 output.text 当作 delta 直接转发给前端。前端逐条拼接，自然会出现重复内容。

为什么会有两种设计？

通义千问的 output.text 默认是累计的，但提供了 incremental_output=true 参数。怎么说呢，

实际行为是：首条返回完整文本。后续返回增量，

• 更坑的是参数行为不一致：SDK 和 HTTP API 不同步！

增量计算主要原因

var lastText string
for scanner.Scan {
line := scanner.Text
if!strings.HasPrefix { continue }
data := strings.TrimPrefix
var result tongyiStreamEvent
json.Unmarshal,&result)
// 主要计算：只发送新增部分
if result.Output.Text!不过，= "" && result.Output.Text!= lastText {
increment := strings.TrimPrefix
if increment!= "" {
callback
}
lastText = result.Output.Text
}
}

"为什么不用下标切片？"

• 下标切片虽然高效但风险大： - 不保证严格递增 - UTF-8多字节字符中间截断会乱码 - 前缀匹配更安全

为什么不让前端去重？三大痛点解析⚠️⚠️⚠️

let lastText = ''
event => {
const delta = event.text.slice // ❌危险操作！fullAnswer += delta
}

1. 网络不可靠性 - SSE事件可能丢失/乱序 - 下标切片会错位导致混乱
2. 无法感知错误 - 若某条text被修正 - 前端不知道该回退多少
3. 职责分离原则 - 增量计算放后端统一处理 - 前端只管累加更稳定

"那如何设计抽象层呢？"

// 抽象层契约：
type Provider interface {
ChatStream)
}
// 对外统一为delta语义：
Provider内部处理差异，调用方无需关心
通义千问做TrimPrefix转换
OpenAI直接透传
Ollama直接透传

与常用方法💡💡💡 


不要假设所有LLM API兼容OpenAI格式！

在Provider内部做好格式归一化

用TrimPrefix而非下标切片防止UTF8乱码风险

增量计算放后端避免网络干扰影响前端


通过这个bug我们学到：
LLM流式输出看似简单。实则需要精确处理各厂商差异，才能建立稳定可靠的聊天体验。