做大模型应用的人都有一个共同体验:流式输出是好,但流式渲染是真难。
模型那边 token 一个一个往外吐,这边前端如果还按"等数据全到了再渲染"的老套路,用户就会看到一段文字慢慢长出来、表格先歪着再变正、代码块半截半截地闪。这种体验,在 jboltai 看来是不可接受的。
这篇文章,我们拆开 jboltai 渲染引擎最核心的那部分——基于状态机的增量解析器,看看一个 token 是怎么一步步变成屏幕上的真实 DOM 的。这是 jboltai 整套流式能力的地基。
为什么传统解析器干不了流式
先说清楚问题在哪。一个常规的 parser,不管是解析 JSON 还是 HTML,基本都假设输入是完整的。它的工作模式是:拿到全部字符串 → 构建语法树 → 输出结果。
但流式场景完全不一样。模型吐给你的可能是这样的:
text
第 1 块: [card tt:第 2 块: 销售报第 3 块: 告]第 4 块: [p 本月第 5 块: 数据]第 6 块: [/card]
你看,第 1 块 [card tt: 是个残废的开标签,属性值都没给完。如果用传统 parser,它要么报错,要么只能干等。但用户已经在屏幕前等着了。
jboltai 的解法是:让解析器有"记忆"。它能记住"我现在正处在某个标签的属性解析中途",每来一块新数据,就从上次断开的地方接着解。这就是状态机的用武之地。
jboltai 的三状态模型
jboltai 的解析器核心就三个状态,简单粗暴但极其有效:
- TEXT:正在读普通文本内容
- TAG_OPEN:正在读一个开标签
[xxx - TAG_CLOSE:正在读一个闭标签
[/xxx
别小看这三个状态,jboltai 用它们就能处理任意嵌套的组件树。我们走一遍真实流程。
假设当前在 TEXT 状态,缓冲区收到字符。遇到 [,jboltai 就知道"要进标签了",先把之前累积的文本作为一个文本节点吐出去,然后切到 TAG_OPEN。在 TAG_OPEN 里继续读,读到的内容可能是组件类型(如 card)、可能是属性(如 tt:标题)、也可能是闭合的 ]。遇到 ],这个标签解析完,jboltai 把它作为一个完整节点交给渲染器,状态切回 TEXT。
关键在"交给渲染器"这一步。jboltai 不是等整棵树建好才渲染,而是每解析出一个完整节点,立刻渲染、立刻挂到 DOM 上。这就是 jboltai 流式渲染的灵魂——边解析边出图。
增量喂入:feed() 的设计
对外,jboltai 暴露的是非常干净的 API:
js
const tokui = new TokUI({ container: '#app' });tokui.startStream(); // 初始化流式状态机tokui.feed('[card tt:'); // 喂第 1 块tokui.feed('销售报告]'); // 喂第 2 块,卡片此刻就渲染出来了tokui.endStream(); // 收尾
每次 feed() 进来,jboltai 做的事是:把新数据拼到内部缓冲区 → 跑状态机尽可能多地消费 → 把消费掉的部分从缓冲区移除 → 剩下的残缺部分留着等下次。
这里有个细节体现了 jboltai 的工程考究:缓冲区永远不会无限增长。每跑完一轮,已解析的内容就被清掉,内存占用稳定。对于动辄几千 token 的长输出,这点至关重要——不然 jboltai 早就被一个大回复撑爆了。
容器嵌套:slotStack 的妙处
光解析单个节点还不够,组件是要嵌套的。卡片里有段落,段落里有链接,表单里有输入框。jboltai 怎么知道一个新节点该挂到哪个父节点下?
答案是渲染器维护了一个插槽栈(slotStack)。每当 jboltai 遇到一个容器型组件(比如 card)的开标签,就把它的 DOM 元素压栈;遇到它的子节点,就挂到栈顶元素里;遇到它的闭标签 [/card],就出栈。
举个 jboltai 的真实例子:
text
[card tt:报告] → 压栈,栈 = [cardEl] [p 本月数据] → 挂到栈顶 cardEl,栈不变 [a u:#详情] → 挂到栈顶 cardEl,栈不变[/card] → 出栈,栈 = []
这套机制让 jboltai 能优雅处理任意深度的嵌套,而且每个节点一解析完就立刻挂到正确的位置——用户看到的就是一个组件从外到内、一点一点长出来的过程,而不是憋半天一次性弹出。
安全与资源防护
解析器还要防两件事,这是 jboltai 在生产环境里被毒打出来的经验。
一是恶意输入。 如果有人喂一个 1MB 的畸形字符串进来,朴素实现会一直缓冲直到 OOM。jboltai 设了 maxBuffer(1MB)和 maxDepth(100 层嵌套)两道闸,超了就拒绝。jboltai 宁可报错也不让一个请求拖垮整个页面。
二是未闭合容器。 流式过程中用户可能中途断开,留下 [card 没闭合。jboltai 在 endStream() 时会自动把栈里没闭合的容器补全,保证 DOM 结构永远是合法的。这是 jboltai 健壮性的体现。
状态机为什么是对的抽象
回头看,jboltai 选状态机不是偶然。它有三个不可替代的优势:
确定性。 同样的输入,状态机永远走同样的路径,行为可预测、可测试。jboltai 的解析器测试套件能覆盖各种边界 case,就是因为状态机让每个分支都显式可见。
增量友好。 状态天然可以暂停和恢复,完美匹配流式的"来一点解一点"。jboltai 不需要重新跑,接着上次的状态继续就行。
性能稳定。 状态机的转移是 O(1) 的,整体复杂度线性于输入长度。jboltai 即便处理超长输出,CPU 也平稳,不会出现传统递归下降 parser 在深层嵌套时的栈溢出。
结语
从 token 到 DOM,中间隔着的是一整套精密的工程。jboltai 用三个状态、一个栈、两道防护,把这件事做到了既快又稳。
如果你正在做 AI 应用,被流式渲染折磨过,理解了这套状态机,你就能明白 jboltai 为什么能做到"首个字符到达就开始画"。这不是魔法,是把每一步都想清楚的结果。jboltai 把这套设计开放出来,正是希望整个行业不再重复造这个轮子。
流式 UI 的关键技术不在模型,在渲染。这是 jboltai 走过弯路后的结论。
