流式界面的可靠性往往藏在一个很小的瞬间网络已经送来两个字节汉字却还没有收全。此时直接显示读者可能看见替换字符直接丢弃内容又少了一截。比起讨论一条请求跨越多少层“宏伟技术栈”先把这个边界处理好更像程序员节应该留下的一件小作品。10月16日更新的WebMCP命令式API文档已经把流式读取和取消信号放进工具执行示例。页面开始成为Agent的操作现场但数据进来、用户取消、内容上屏依然是前端自己的责任。下面只处理其中最基础的一层字节变成文本。网络分片不负责替你切好汉字“墨”的UTF-8字节是E5 A2 A8。网络读取可能恰好得到E5 A2和A8两块也可能把多个字放进同一块。应用层不能假定一次read()对应一个字符更不能把它等同于一个模型Token。Encoding标准提供了增量解码器。TextDecoderStream的构造器参数是编码标签和解码选项stream: true则是TextDecoder.decode()的选项。两套写法不要拼成new TextDecoderStream({ stream: true })。一个不依赖模型接口的最小实验以下代码保存成decode.mjs后用Node运行。它主动把汉字切开检查第一块暂不产生文本最后仍然还原为“墨”。fatal: true让残缺的最终字节暴露为错误而不是悄悄替换。import assert from node:assert/strict; const bytes new TextEncoder().encode(墨); const decoder new TextDecoder(utf-8, { fatal: true }); const first decoder.decode(bytes.slice(0, 2), { stream: true }); const second decoder.decode(bytes.slice(2), { stream: true }); const tail decoder.decode(); // 结束时冲刷内部缓冲 assert.equal(first, ); assert.equal(first second tail, 墨); const stream new ReadableStream({ start(controller) { controller.enqueue(bytes.slice(0, 2)); controller.enqueue(bytes.slice(2)); controller.close(); } }).pipeThrough(new TextDecoderStream(utf-8, { fatal: true })); let text ; for await (const chunk of stream) text chunk; assert.equal(text, 墨); const broken new TextDecoder(utf-8, { fatal: true }); broken.decode(bytes.slice(0, 2), { stream: true }); assert.throws(() broken.decode(), TypeError); console.log(UTF-8 split and incomplete-tail checks passed);这里的断言检查的是编码语义。它没有测量网络速度、模型首字延迟或浏览器绘制时间也不说明某种前端框架比另一种快多少。解码完成还没到可以随意写入HTML的时候解码层输出字符串SSE层负责事件边界业务层决定增量是追加还是替换视图层决定安全显示。四者各有自己的状态。解码正确的字符串仍可能包含未完成的Markdown链接或HTML片段把它直接交给innerHTML会引入另一类问题。纯文本可以追加到已有文本节点。富文本需要相应的解析与清洗策略。用户取消时应停止读取并结束当前会话收到流结束也要区分业务完成与意外截断。不要让一个“已完成”的绿色提示掩盖最后几个字节还未被确认的事实。1024的纪念意义可以很具体一条断言说明会发生什么一条失败用例说明不能发生什么。文字完整地抵达屏幕比没有证据的纳秒故事更值得留下。本文最小实验在Node v26.3.0运行未接入真实模型、SSE服务器或浏览器渲染管线。