边缘函数与流式 AI 响应：从请求转发到逐字显示
§1 第一步：设计浏览器到模型的流式链路
先把链路分成三段：浏览器提交消息，边缘函数请求模型接口，浏览器持续显示返回内容。把边缘函数定位为轻量转发层，不要等完整回答生成后才返回。流式响应让用户更早看到内容，但不代表模型完成整段回答的时间一定缩短。([vercel.com](https://vercel.com/docs/functions/streaming-functions?utm_source=openai))
本次建议采用上游事件流原样透传、浏览器负责解析的方案。边缘函数直接把上游响应体交给新的响应对象，避免额外收集完整正文；需要加工内容时，再引入流式转换。([developers.cloudflare.com](https://developers.cloudflare.com/workers/runtime-apis/streams/))
§2 第二步：配置 Fluxio 密钥与请求参数
需要统一接入多个模型时，可以考虑 Fluxio。根据本次提供的服务信息，它采用流式优先、按令牌付费的方式，一把密钥即可访问多个模型，适合减少接入层的重复配置。
将密钥保存在边缘平台的机密配置中，浏览器只请求自己的聊天接口。以 Gemini 2.5 Flash 为例，先在服务控制台确认实际模型标识，再配置到服务端白名单，不要把展示名称直接当作接口标识。
- – 把上游主机配置为 api.fluxioapi.com，并使用带 /v1 的兼容接口路径。
- – 让聊天请求携带消息列表、已确认的模型标识，以及值为 true 的 stream 参数。
- – 在服务端校验登录状态、消息长度和允许使用的模型，拒绝客户端任意指定上游地址。
§3 第三步：让边缘函数立即转发响应体
收到请求后，先完成参数检查，再通过 fetch 发起上游请求。检查上游状态与响应体是否有效，然后以其 body 创建返回给浏览器的响应。不要先调用 text() 或 json() 读取完整正文，否则会破坏这条链路的实时转发方式。([developers.cloudflare.com](https://developers.cloudflare.com/workers/runtime-apis/streams/))
对于事件流，保留正确的 text/event-stream 内容类型，并为聊天接口设置不缓存策略。上线时还应检查中间代理是否缓冲响应；事件流的正确格式和持续发送同样重要。([developer.mozilla.org](https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events))
§4 第四步：在浏览器增量解析事件内容
浏览器通过 fetch 提交消息后，从响应体读取数据块。使用同一个 TextDecoder 持续解码，并在分块阶段开启流式解码，结束时再刷新剩余内容，避免跨块字符被错误处理。([developer.mozilla.org](https://developer.mozilla.org/en-US/docs/Web/API/TextDecoder/decode))
不要把一次读取当成一个完整事件。先将文本追加到缓冲区，再按事件之间的空行切分，保留尚未完整的尾部；处理完整事件的数据字段后，再提取实际文本增量。事件流以空行分隔消息，因此网络分块边界不能替代事件边界。([developer.mozilla.org](https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events))
§5 第五步：区分请求失败与生成中断
建议把错误处理分成两个阶段：开始转发前，将鉴权失败、参数错误或上游异常转换为明确提示；已经显示部分回答后，保留现有文本并标记“生成中断”，不要静默重新请求并拼接另一份回答。
同时设计停止按钮、请求超时和重复提交保护。把“等待首段内容”“正在生成”“正常结束”“已中断”设为独立界面状态，便于用户判断当前进度，也便于定位故障发生在哪一段。
§6 第六步：验证首字延迟与流式完整性
部署后，建议同时记录请求开始、首段可见文本和生成结束三个时间点。用较长回答检查内容是否持续出现，而不是最后一次性弹出；再用中文、换行和弱网场景检查解析是否完整。
- – 验证无效密钥与上游错误能产生清晰提示，而不是空白聊天气泡。
- – 验证停止生成后界面状态正确，并检查上游请求是否及时终止。
- – 验证日志不包含密钥，且不会默认保存完整的敏感对话。
注册 Fluxio，开始搭建你的流式 AI 应用。