Java SSE 转发实战

Java SSE 转发真正要解决的，不是“把流拿过来再发出去”这么简单，而是让一条来自 AI 服务的增量结果，在经过认证、额度、日志和错误处理后，仍然能稳定送到浏览器。

所以它本质上是业务入口层对流式能力的一次接管，而不是纯转发。

为什么前端不该直连内部 AI 服务

只要系统里有登录、额度、审计或权限，前端就不该直接连内部 AI 服务。因为真正需要控制的是：

• 谁能发起这次请求。
• 这次请求是否还有额度。
• 这次流式调用最终怎样记日志。
• 中途断开或报错该怎么算。

这些都不该留给浏览器自己处理。

一条流式调用通常要接住什么

一次实际的 SSE 转发，至少要接住：

• 建链前校验身份和额度。
• 建链后持续转发增量事件。
• 中途错误时给前端明确状态。
• 完成后写入日志并结算。

真正麻烦的地方，不是“流会不会流出来”，而是异常路径和收尾路径。

最容易漏掉的收尾动作

很多实现只在 happy path 上做得很好，一旦浏览器断开、下游超时、模型半路失败，系统就开始出现：

• 日志没写全
• 额度没结算
• 状态停在半路

所以 SSE 的关键，不只是开始流，而是怎样正确结束。

一句话先记住

SSE 转发不是把字节转给前端，而是把一条受治理的流式调用交付给前端。

继续阅读

• 02-llm-basic/003-streaming-response.md
• 09-ai-agent-engineering/002-ai-call-log.md