使用 DeepSeek API 的流式输出构建对话应用时，响应中途断开、客户端收到不完整数据是常见问题。本文基于通用工程实践梳理排查思路与应对方案。需要说明的是，本文未逐项核验官方文档中的具体错误码和配置参数，所有具体配置值需以实际环境为准，并建议优先查阅官方文档中关于流式传输、超时和错误处理的说明。本文不提供 DeepSeek 官方具体重连参数，标题中的“配置”指通用客户端与代理的超时配置思路。
现象归类与初步判断
流式响应中断通常表现为：连接意外关闭、收到部分数据后停滞、或客户端抛出读取超时异常。首先应区分问题发生在哪一层：
- 网络层超时：连接建立阶段或传输过程中因网络不稳定导致 TCP 连接断开。
- 代理缓冲：中间代理（如 Nginx、负载均衡器）缓冲了 SSE 数据，导致客户端无法实时收到分块。
- 客户端读取超时：客户端设置的读取超时时间过短，在服务端尚未发送下一块数据时主动断开。
- 服务端返回错误：服务端因限流、内部错误等原因主动终止流，可能伴随错误信息。
区分原因的关键手段
- 检查客户端超时配置：确认连接超时和读取超时是否合理。流式响应中，读取超时通常应按两次数据块之间的空闲间隔设置，而非固定覆盖整个流式传输周期。若客户端只支持总超时，需按最大流时长评估并明确风险。
- 观察代理行为：若使用反向代理，检查是否启用了响应缓冲。SSE 要求代理不缓冲响应体，需关闭缓冲并适当延长超时。
- 捕获服务端错误：在流式读取过程中，若收到非数据事件（如 error 事件），应记录完整错误信息，判断是否为服务端主动终止。
- 网络抓包分析：在复杂网络环境下，通过抓包确认连接是否被中间设备重置。
超时配置调整建议
- 连接超时：设置为较短时间（如 5-10 秒），快速失败以便重试。
- 读取超时：优先采用空闲超时机制，即两次数据块之间的最大间隔（如 30-60 秒）。若客户端仅支持总超时，需按最大流时长评估，并注意长时间但持续有数据的流可能被提前断开的风险。
- 代理超时：确保代理的读超时大于应用层空闲超时，避免代理提前断开。
SSE 解析中的半包与重连
SSE 数据以 \n\n 或 \r\n\r\n 分隔事件，网络传输可能将事件拆分为多个 TCP 包。客户端需维护字节缓冲区，按分隔符切分完整事件后再解码。注意不要逐 chunk 直接 decode()，因为多字节字符可能被 TCP 分片截断，导致解码错误。应使用字节缓冲增量解析，兼容两种分隔符。以下为通用 SSE 解析示例，DeepSeek API 的事件字段、错误事件和重连语义应以官方文档或实测为准：
buffer = b""
for chunk in response.iter_content():
buffer += chunk
while True:
# 查找 \r\n\r\n 或 \n\n 分隔符
idx_n = buffer.find(b"\n\n")
idx_rn = buffer.find(b"\r\n\r\n")
if idx_n == -1 and idx_rn == -1:
break
# 取最早出现的分隔符
if idx_rn != -1 and (idx_n == -1 or idx_rn < idx_n):
event_bytes = buffer[:idx_rn]
buffer = buffer[idx_rn + 4:]
else:
event_bytes = buffer[:idx_n]
buffer = buffer[idx_n + 2:]
event = event_bytes.decode("utf-8")
process_event(event)
# 剩余不完整事件保留在 buffer 中，等待下一 chunk
重连时需注意：若流已部分消费，应记录最后收到的事件 ID（若服务端提供），并在重连请求中携带，以避免重复数据。若无事件 ID，则需在应用层根据消息内容去重。
应用层幂等重试
为避免重复计费与消息重复，重试策略应遵循：
- 区分可重试错误：网络超时、连接重置通常可重试。对于 HTTP 状态码，408（请求超时）、429（限流）等通常需要按退避策略重试；其他 4xx 客户端错误（如 400、401、403）一般不应重试，除非官方文档明确说明可重试。5xx 服务端错误通常可重试。
- 限制重试次数与退避：采用指数退避，避免加重服务端负担。
- 幂等键：在请求头或请求体中携带唯一请求 ID，服务端若支持幂等处理，可避免重复生成。
- 客户端去重：在消息列表中根据消息 ID 或内容哈希去重，确保用户界面不出现重复消息。
工程取舍
流式响应的稳定性需要在实时性与可靠性之间权衡。较长的空闲超时可减少误断，但会延长故障发现时间；激进的重试可能增加计费风险。建议在监控中记录中断率与重试成功率，根据实际网络状况动态调整参数。
在未获取官方细节的情况下，以上建议需结合 DeepSeek API 的实际文档与错误码进行验证。开发者应优先查阅官方文档中关于流式传输、超时和错误处理的说明，并在测试环境中模拟中断场景，验证重连与去重逻辑的有效性。