一、使用者痛点：页面完全卡死

当模型侧快速推送流式数据时页面完全卡死无法操作。通过 Performance Monitor 工具分析结果如下：

• CPU 占用持续 九十成左右+ s界面完全无法操作。话说回来，
• 频繁 GC内存曲线锯齿状波动。
• DOM 节点数阶梯式波动与 GC 频率一致。
• 思考过程和回答正文生成阶段尤为明显。

二、失效方案速览：传统 React 性能调整无效

在找到正确解法前，我们尝试了所有常规 React 性能调整手段。全部无效：

三、根因分析：推送频率过高导致 UI 层过载

关键痛点的观点是。模型侧高频推送 chunk，导致 UI 层短时间内需要响应大量状态更新，线程被阻塞。

`useChat` 的数据流

`useChat` 返回的 `messages` 是一个 React state。每当 stream 中有新 chunk 到达时：

│ ▼ 解析 SSE 事件 ← 从 HTTP stream 中解析出 UIMessageChunk
│ ▼ 创建新 messages 对象 ← 不可变更新：新数组 + 新消息对象 + 新 parts 对象
│ ▼ 调用 setMessages ← 触发 React 状态更新
│ ▼ Chat 组件重渲染 ← 执行函数体、创建 React 元素、reconciliation
│ ▼

React 层的 ``useDeferredValue``。``useThrottle`` 和 ``memo`` 都是作用在步骤上，无法从源头降低推送频率。

为什么直接在组件层节流无效？

即使把节流调到 0.1 s，`useChat`仍然在每秒处理+个 chunk。每次都触发 `setMessages` → React 调度更新 → 组件函数执行。这些开销无法通过 React API 消除，因为 `chunk 到达的频率无法从组件层控制`。

Vercel AI SDK 的 Transport 架构

useChat
└── transport.sendMessages ← 返回 ReadableStream
└── HttpChatTransport ← 发起 HTTP fetch。解析 SSE
└── processResponseStream ← Uint8Array → UIMessageChunk

如果能在这个 stream 上加一个“节流阀”，就能从源头控制 `useChat` 收到数据的频率。

四、方法：Transport 队列节流

解决思路 & 三大关键设计：

1. `requestIdleCallback` 驱动输出：只在浏览器主线程空闲时推送，自适应背压机制。话说回来，CPU 忙时回调延后；CPU 空闲时立即执行，不过，
2. 每次只推一条：确保 `useChat` 每次处理增量最小。以免一次性大量 chunk 导致线程阻塞。避免批量爆发造成 CPU 峰值。
3. 队列上限背压：** - 队列满时暂停读取。- 防止内存无限增长，按理说，取消时主动清理回调与队列以防泄漏。

完整实现

import { DefaultChatTransport。type ChatTransport,type HttpChatTransportInitOptions,type UIMessage,type UIMessageChunk } from 'ai';export class ThrottledChatTransport extends DefaultChatTransport {
private readonly idleTimeoutMs!: number，constructor {
const { idleTimeoutMs = 100,...transportOptions } = options?，{};super，this.idleTimeoutMs = idleTimeoutMs;}
// 重写 sendMessages 与 reconnectToStream，让返回 stream 经由 throttleStream 包装
override async sendMessages(options:
Parameters>) : Promise {
const stream = await super.sendMessages;return this.throttleStream;}
override async reconnectToStream(options:
Parameters>) :
Promise<(ReadableStream&ltUIMessageChunk>> | null>
{
const stream = await super.reconnectToStream;不过，if return null;怎么说呢，return this.throttleStream;}
private throttleStream :
ReadableStream
{
const reader = stream.getReader;const queue : UIMessageChunk =;const MAX_QUEUE_SIZE = Math.floor / );// 可调
const state : any = {
flushScheduled : false,sourceDone : false,cancelled : false,readIndex : 0。idleHandle : undefined as number | undefined | null,controller : null as ReadableStreamDefaultController | null,};const cancelIdle = => {
if return;const ric =
=>void })
.cancelIdleCallback?，=>clearTimeout);ric，state.idleHandle = null;}，const flush = => {
state.flushScheduled = false;state.idleHandle = null;if return，const controller = state.controller!，try {
// 每次仅推一条
if {
controller.enqueue;
说起来，state.readIndex++;}
// 清空已消费完毕的数据块
if {
queue.length = 0;state.readIndex=0;}
// 若还有剩余则继续排下一次 flush，否则检查是否结束
if scheduleFlush;else if controller.close;} catch {}
};const scheduleFlush = => {
if return;state.flushScheduled=true;const ric =
(globalThis as { requestIdleCallback?:(
从cb来看，=>void),opts?:{timeout:number}
)=>number|undefined }).requestIdleCallback?，=>void),opts:{timeout:number})=>setTimeout);state.idleHandle=ric;}，// new readable stream that consumes source asynchronously
return new ReadableStream({
async start{
state.controller=controller;try{
for{
// 背压：队列满时暂停读取等待消费追赶
while{
ifreturn;ifscheduleFlush;await new Promise);}
const {done,value}=await reader.read;if{
state.sourceDone=true;if
controller.close;else scheduleFlush;break，}
queue.push;scheduleFlush;}
}catch{
if
try{controller.error}catch{}
}finally{
reader.releaseLock;}
},cancel{
state.cancelled=true;cancelIdle，queue.length=0;void reader.cancel;}
})，按理说，}
}

使用方式示例的观点是。

// Chat.tsx
import { ThrottledChatTransport } from '@/lib/throttled-transport';const = useState =>
new ThrottledChatTransport({
idleTimeoutMs : 100,// 浏览器忙碌时最多等100ms再强制推一条
body : =>
})
);const { messages,...rest }= useChat;...
// 渲染部分省略…，

调整后数据流图示：

模型推送 chunk
│▼HTTP fetch → ReadableStream
│▼DefaultChatTransport.processResponseStream ← 解析为 UIMessageChunk
│▼queue.push ← 入队
│├───────── 队列 ≥ MAXQUEUESIZE ────────┐
││ 否 │
││ 是 │
││ ↓ ↓
││ 暂停 reader.read
│└─────────────────────────────────────┘
│▼requestIdleCallback
│ 浏览器空闲时触发 → 出队→ useChat→ 渲染
└───────────────────────────────────────┘

使用 requestIdleCallback 能让 CPU 空闲才工作；只取一条保证增量最小，背压防止内存膨胀。不过，

五、关键设计决策详解 &User Pain Points Highlighted Here!

• # 为什么用 requestIdleCallback 而不是 setTimeout？ "CPU 忙时回调延后不往 useChat 塞数据；CPU 空闲时立即执行，" – 避免雪崩现象，让界面保持可交互性。