聊天类产品的体感差距几乎全在流式：服务端开 stream=True 逐块转发、前端逐块渲染，并处理「首 token 前失败可重试、生成中途断开不可无脑重试」的区别。中文实操文把超时拆成连接、首事件（TTFT）、事件间、总时长四层，只设一个总超时必然误杀长回答或迟迟发现不了死连接。
适用场景：做聊天机器人、写作助手、客服等需要打字机效果和低首字延迟的产品。
streaming sse python javascript ttft ux
操作步骤
- 请求带
stream=True，逐 chunk 累积delta.content并立即输出/推送给前端。 - 给四层超时分别设值：连接 5–10s、首事件按输入长度 10–120s、事件间 15–30s、总时长按预期输出估算。
- 流式中途断开时，长回答提示用户重试或接受部分结果，不要自动从头重跑（会双倍计费）。
代码示例
from openai import OpenAI
client = OpenAI(base_url="https://tokenbuddy.cc/v1", api_key="{{API_KEY}}", timeout=60)
stream = client.chat.completions.create(model="your-model-id",
messages=[{"role": "user", "content": "写一段产品介绍"}], stream=True)
for chunk in stream:
delta = chunk.choices[0].delta.content or ""
print(delta, end="", flush=True)接入本站 API：先确认本站所选模型支持流式（用上面代码实测），再设计 UI；服务端要关掉反向代理的缓冲（如 Nginx
proxy_buffering off），否则前端看不到逐字效果。注意事项
- ⚠️ 把完整回答攒完再一次性返回 = 假流式，用户等得最久
- ⚠️ 只设一个总超时：短了误杀长回答，长了死连接半天发现不了
- ⚠️ 流式重试策略和普通请求不同，首 token 前后要分开处理
来源：https://arganzheng.life/llm-client-engineering-retries-timeouts-streaming-and-rate-limits.html