Web Shell 流式渲染性能优化qwen-code 终端 AI 助手的流式渲染优化设计解析【免费下载链接】qwen-codeAn open-source AI coding agent that lives in your terminal.项目地址: https://gitcode.com/GitHub_Trending/qw/qwen-code导读本文基于 qwen-code 仓库中的设计文档 docs/design/web-shell-stream-render-performance.md深入剖析 Web Shell 在流式输出streaming场景下主线程渲染性能问题的根因、优化方案与验证方式。文章覆盖从「逐帧唤醒 transcript 渲染」到「50ms 节流 延迟快照 流式纯文本降级 历史投影身份复用」的完整技术路径并辅以仓库源码实现hooks、MessageList、Playwright 性能测试脚本作为佐证。读完本文你将掌握一套可复用的「长会话流式渲染」性能优化方法论并能直接定位 qwen-code Web Shell 中对应的实现位置。一、问题每次动画帧都唤醒 transcript主线程不堪重负在 qwen-code 的 Web Shellpackages/web-shell中Thinking 与 assistant 的增量内容delta在流式输出时会在每个动画帧animation frame上唤醒 transcript 渲染。这意味着每个被接受的快照snapshot都会触发一次 transcript 投影projection与下游列表list处理随着响应的增长不断变大的 Markdown 文档会在每次流式 flush 时被整体重新解析尽管ChatEditor已被 memo 化但主线程上的这些工作仍会与编辑器输入editor input竞争当活跃响应active response不断增长时成本愈发昂贵。问题的本质是「成本与流式增量不成比例」每次网络 chunk 到达都会通知 store而每次渲染都要执行一遍 O(transcript) 的归一化normalization与投影。如果以 60fps 渲染每秒的成本就是 20fps 的三倍——但用户可见的文本本身受 80ms 的 Markdown 节流限制根本不可能变化得那么快。二、证据性能剖析揭示的瓶颈分布设计文档给出了浏览器 profiling 的具体数据说明瓶颈不在transcript 投影本身而在其下游的衍生计算环节剖析结果transcript 投影线性linear算法在保留 50,000 条消息的会话中仅占采样时间的2.5%主导的长任务104 ms 的长任务中52.1 ms花在applyTurnCollapse上全量历史推导MessageList反复进行全量历史推导其中包含 final-answer 收集、agent 分组、置顶pinning以及显示索引display-index生成走「仅尾部tail-only」路径后的实测收益在改为仅处理尾部增量之后两次 CPU 采样显示各热点显著下降热点计算优化前总 self time优化后applyTurnCollapse467.8 ms26.7–51.5 msfinal-answer 收集247.2 ms11.4–26.9 msagent 分组grouping54 ms2.4–7.6 ms显示索引生成67.5 ms3.7–12 ms注意该次重跑中 mock SSE 在 replay 后断开连接因此这些采样数据仅用于证明热点被消减不作为端到端完成时间或长任务验收long-task acceptance的正式证据——正式验收依赖后文所述的 Playwright 性能测试。Markdown 的相反形态与 transcript 投影不同Markdown 解析呈现相反的形态每次流式 append 都会改变完整的源字符串从而重新解析整个不断增长的文档。节流throttling只能限制解析发生的频率却无法降低单次解析的成本——这是第 5 条设计决策的直接动因。三、设计六项措施组合拳设计文档给出了六条核心设计决策逐条拆解如下。3.1 事件批处理16ms 宏任务窗口 50ms 快照节流Provider 侧将 transcript 事件批处理进一个16 ms 的宏任务macrotask窗口并在以下时机执行同步 flush控制事件control events之前终端事件terminal events之前流结束stream ends时。下游侧合并 transcript 通知coalesce并且每 50 ms 最多接收一个快照。对应的源码实现位于 packages/web-shell/client/hooks/useAnimationFrameTranscriptBlocks.ts其中定义了三个关键常量// Cap transcript re-renders at ~20fps. During streaming every network chunk // notifies the store; each render then runs the O(transcript) normalization // pass, so rendering at 60fps triples that cost per second while the visible // text (itself throttled at 80ms for markdown) cannot change that fast. const TRANSCRIPT_RENDER_THROTTLE_MS 50; const INPUT_QUIET_WINDOW_MS 100; const MAX_INPUT_DEFERRAL_MS 250;TRANSCRIPT_RENDER_THROTTLE_MS 50将 transcript 渲染上限限制在约 20fps与流式文本的实际可见变化速度匹配INPUT_QUIET_WINDOW_MS 100输入静默窗口期间若有输入则推迟渲染MAX_INPUT_DEFERRAL_MS 250输入推迟的上限避免因持续输入而永久饿死渲染。调度逻辑通过requestAnimationFrame实现当距上次通知不足 50ms、或存在即将到来的输入利用navigator.scheduling?.isInputPending?.()探测时不立即notify()而是继续请求下一帧直至满足条件或达到最大推迟上限const dispatchWhenDue (ts: number) { frame null; if ( ts - lastNotifyTs TRANSCRIPT_RENDER_THROTTLE_MS ((ts - lastInputTs INPUT_QUIET_WINDOW_MS !hasPendingInput()) || (pendingSinceTs ! null ts - pendingSinceTs MAX_INPUT_DEFERRAL_MS)) ) { lastNotifyTs ts; pendingSinceTs null; notify(); } else { frame window.requestAnimationFrame(dispatchWhenDue); } };同时hook 通过document.addEventListener(beforeinput, recordInput, true)记录输入时间戳并在卸载时正确清理订阅与动画帧避免泄漏。3.2 延迟快照session 身份 block-index 身份双重保护设计要点延迟defertranscript 快照并携带 session 与 block-index 身份。紧急的编辑器工作如用户正在打字可以基于上一个快照提交无需等待最新快照session 切换时旧 session 的延迟块被立即拒绝同一 session 内的 store 重置也会通过 block-index 身份立即拒绝陈旧的延迟块stale deferred blocks而不会阻塞普通的流式文本更新。源码中快照通过useSyncExternalStore订阅并用useMemo(() ({ sessionId, ...live }), [live, sessionId])将sessionId与实时快照绑定在一起// Session and block-index identities ride inside the deferred snapshot. The // session id rejects a previous session, while the index identity rejects a // same-session store reset without blocking ordinary streamed text updates. const snapshot useMemo(() ({ sessionId, ...live }), [live, sessionId]);在此基础上useDeferredValue保证流式渲染帧永远不会排在紧急更新输入、按钮点击之后实现「流式保持顺滑、打字保持响应」的双赢。3.3 WeakMap 保留归一化的工具内容引用为了让现有行比较器row comparator的 JSON 缓存发挥作用设计用WeakMap保存归一化后的工具内容normalized tool-content引用从而避免对未变化的历史工具输出进行重复序列化reserializing。这项设计的意义在于流式输出期间历史工具调用结果并没有变化若每次渲染都重新序列化比对成本会随历史长度线性增长借助WeakMap引用 JSON 缓存比较器可以快速判定「未变化」并跳过。3.4 保持 thinking 计时器存活流式内容 append 时thinking 的 elapsed 计时器必须保持存活keep alive而不是在每次内容追加时被重置或销毁。否则用户在长思考过程中会看到计时器反复归零且重复创建/销毁计时器本身也会带来额外开销。3.5 流式纯文本降级短响应保 Markdown长响应限成本这是对「Markdown 全量重解析」问题的直接回应短响应继续保持实时 Markdown渲染让已折叠的图表closed charts与普通格式ordinary formatting保持既有行为不变长响应一旦流式文档超过固定的解析预算fixed parse budget则将其节流后的源码渲染为保留空白符的转义纯文本escaped plain text with preserved whitespace流结束时一次性渲染完整 Markdown。这样既限制了重复解析的次数与成本又只推迟了大到足以引发问题的响应的格式化普通小响应的体验完全不受影响。3.6 投影身份复用仅尾部增长时复用历史推导最后一条设计针对MessageList的全量历史推导当所有历史 transcript block 均未变化且只有最后一个普通流式文本块在增长时保留投影后的历史对象身份identity不变在此窄条件下复用已完成历史的MessageList推导结果仅替换渲染的尾部行tail row任何更早 block 的变化、终端状态转换、工具/后台更新、usage 变化、翻译变化或视图选项变化都走原有全量计算路径。这条决策与第 3.1 节中的「tail-only 路径」共同构成了性能收益的主要来源——applyTurnCollapse、final-answer 收集、分组与显示索引生成等热点都因此从「全量重算」变为「只算增量」。四、Non-goals明确不做的事设计文档明确划定了边界避免过度设计不做通用的增量 transcript 投影器投影不是实测瓶颈窄化的 tail 路径避免了引入新的失效invalidation机制不做增量 Markdown AST也不引入 Web Worker纯文本流式渲染以更少的代码消除了重复解析且无需跨线程序列化cross-thread serialization不改 daemon 事件顺序、transcript 持久化或公开 block 结构所有优化都收敛在 Web Shell 客户端渲染层对外契约零变更。这些「不做什么」与「做什么」同样重要——它保证了优化方案的可落地性与可维护性。五、验证单元测试 Playwright 性能回归5.1 单元测试覆盖清单设计文档要求单元测试覆盖以下场景每项都对应一个具体的失效风险点通知合并notification coalescing多次 store 通知只触发一次渲染50ms 窗口渲染频率被正确节流取消cancellation卸载/切换时动画帧与订阅被正确清理session 切换旧 session 的延迟块被拒绝稳定的投影身份stable projection identity仅尾部增长时历史身份保持不变流式尾部渲染与失效streamed-tail rendering and invalidation尾部行的替换逻辑与失效条件稳定的工具归一化stable tool normalizationWeakMap 引用缓存行为计时器复用timer reusethinking elapsed 计时器跨 append 存活流式文本到稳定 Markdown 的转换streaming-text-to-settled-Markdown transition长响应降级为纯文本、流结束后恢复完整 Markdown 渲染。这些场景在仓库中对应 packages/web-shell/client/hooks/useAnimationFrameTranscriptBlocks.test.tsx节流与调度、packages/web-shell/client/components/MessageList.test.ts 与 MessageList.dom.test.tsx投影、turnCollapse 与 DOM 行为等测试文件中均有实现。5.2 Playwright 性能端到端测试设计文档规定通过 Web Shell 工作区的性能测试命令进行确定性回归验证npm run test:e2e:perf --workspaceqwen-code/web-shell该命令在 packages/web-shell/package.json 中的真实定义为test:e2e:perf: cross-env WEB_SHELL_PERF1 playwright test --config playwright.config.ts --grep perf --projectchromium它通过WEB_SHELL_PERF1环境变量启用性能模式用--grep perf只筛选性能测试用例并在 chromium 项目中运行。测试内容为确定性回放 5,000 个历史轮次historical turns边打字边流式灌入 400 个 Markdown 密集型 chunkMarkdown-heavy chunks校验最终输出与 composer 内容的正确性在 Playwright 报告中记录输入延迟input latency与浏览器长任务long-task指标。该测试同时覆盖「正确性」与「性能」两个维度内容必须与预期一致同时输入延迟与长任务指标必须达标二者缺一不可。六、源码阅读路线图如果你希望深入代码验证上述设计推荐按以下路径阅读节流与延迟快照packages/web-shell/client/hooks/useAnimationFrameTranscriptBlocks.ts —— 三个时间常量、isInputPending探测、rAF 调度与useDeferredValue投影热点packages/web-shell/client/components/MessageList.tsx ——applyTurnCollapse的定义约第 1872 行与调用点约第 3657 行以及TurnCollapseHead类型与折叠行的渲染逻辑身份复用MessageList.tsx中基于blockChangeSummary.source与tailAppendBarrierRevision的结构相等性判断对应 hook 中的isSameTranscriptStructure性能回归入口packages/web-shell/package.json 中的test:e2e:perf脚本。七、经验总结从本设计可迁移的方法论这篇设计文档虽然针对 qwen-code 的 Web Shell但其优化思路具有普适性先剖析再优化用 profiling 数据说话——投影只占 2.5%却差点被当成优化重点真正的热点在applyTurnCollapse与全量推导按可见性定价渲染频率文本 80ms 节流、transcript 50ms 节流、事件 16ms 批处理渲染频率与人类可感知的变化速度匹配即可不必追求 60fps给紧急工作让路isInputPending 延迟快照 最大推迟上限让编辑器输入永远不被流式渲染排队阻塞用身份而非内容做缓存WeakMap引用 block/session 身份 投影对象身份复用用「不变则跳过」替代「全量重算」明确 Non-goals不做通用增量投影器、不做 Worker、不改 daemon 契约控制方案复杂度保证可维护性正确性与性能一起验证Playwright 既校验最终输出与 composer 内容又记录输入延迟与长任务指标防止「优化了性能、破坏了功能」。如果当前项目同样面临「长会话 流式输出导致主线程卡顿」的问题本文的六项措施与验证思路可以直接作为设计与验收的参考蓝本。【免费下载链接】qwen-codeAn open-source AI coding agent that lives in your terminal.项目地址: https://gitcode.com/GitHub_Trending/qw/qwen-code创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Web Shell 流式渲染性能优化：qwen-code 终端 AI 助手的流式渲染优化设计解析
Web Shell 流式渲染性能优化qwen-code 终端 AI 助手的流式渲染优化设计解析【免费下载链接】qwen-codeAn open-source AI coding agent that lives in your terminal.项目地址: https://gitcode.com/GitHub_Trending/qw/qwen-code导读本文基于 qwen-code 仓库中的设计文档 docs/design/web-shell-stream-render-performance.md深入剖析 Web Shell 在流式输出streaming场景下主线程渲染性能问题的根因、优化方案与验证方式。文章覆盖从「逐帧唤醒 transcript 渲染」到「50ms 节流 延迟快照 流式纯文本降级 历史投影身份复用」的完整技术路径并辅以仓库源码实现hooks、MessageList、Playwright 性能测试脚本作为佐证。读完本文你将掌握一套可复用的「长会话流式渲染」性能优化方法论并能直接定位 qwen-code Web Shell 中对应的实现位置。一、问题每次动画帧都唤醒 transcript主线程不堪重负在 qwen-code 的 Web Shellpackages/web-shell中Thinking 与 assistant 的增量内容delta在流式输出时会在每个动画帧animation frame上唤醒 transcript 渲染。这意味着每个被接受的快照snapshot都会触发一次 transcript 投影projection与下游列表list处理随着响应的增长不断变大的 Markdown 文档会在每次流式 flush 时被整体重新解析尽管ChatEditor已被 memo 化但主线程上的这些工作仍会与编辑器输入editor input竞争当活跃响应active response不断增长时成本愈发昂贵。问题的本质是「成本与流式增量不成比例」每次网络 chunk 到达都会通知 store而每次渲染都要执行一遍 O(transcript) 的归一化normalization与投影。如果以 60fps 渲染每秒的成本就是 20fps 的三倍——但用户可见的文本本身受 80ms 的 Markdown 节流限制根本不可能变化得那么快。二、证据性能剖析揭示的瓶颈分布设计文档给出了浏览器 profiling 的具体数据说明瓶颈不在transcript 投影本身而在其下游的衍生计算环节剖析结果transcript 投影线性linear算法在保留 50,000 条消息的会话中仅占采样时间的2.5%主导的长任务104 ms 的长任务中52.1 ms花在applyTurnCollapse上全量历史推导MessageList反复进行全量历史推导其中包含 final-answer 收集、agent 分组、置顶pinning以及显示索引display-index生成走「仅尾部tail-only」路径后的实测收益在改为仅处理尾部增量之后两次 CPU 采样显示各热点显著下降热点计算优化前总 self time优化后applyTurnCollapse467.8 ms26.7–51.5 msfinal-answer 收集247.2 ms11.4–26.9 msagent 分组grouping54 ms2.4–7.6 ms显示索引生成67.5 ms3.7–12 ms注意该次重跑中 mock SSE 在 replay 后断开连接因此这些采样数据仅用于证明热点被消减不作为端到端完成时间或长任务验收long-task acceptance的正式证据——正式验收依赖后文所述的 Playwright 性能测试。Markdown 的相反形态与 transcript 投影不同Markdown 解析呈现相反的形态每次流式 append 都会改变完整的源字符串从而重新解析整个不断增长的文档。节流throttling只能限制解析发生的频率却无法降低单次解析的成本——这是第 5 条设计决策的直接动因。三、设计六项措施组合拳设计文档给出了六条核心设计决策逐条拆解如下。3.1 事件批处理16ms 宏任务窗口 50ms 快照节流Provider 侧将 transcript 事件批处理进一个16 ms 的宏任务macrotask窗口并在以下时机执行同步 flush控制事件control events之前终端事件terminal events之前流结束stream ends时。下游侧合并 transcript 通知coalesce并且每 50 ms 最多接收一个快照。对应的源码实现位于 packages/web-shell/client/hooks/useAnimationFrameTranscriptBlocks.ts其中定义了三个关键常量// Cap transcript re-renders at ~20fps. During streaming every network chunk // notifies the store; each render then runs the O(transcript) normalization // pass, so rendering at 60fps triples that cost per second while the visible // text (itself throttled at 80ms for markdown) cannot change that fast. const TRANSCRIPT_RENDER_THROTTLE_MS 50; const INPUT_QUIET_WINDOW_MS 100; const MAX_INPUT_DEFERRAL_MS 250;TRANSCRIPT_RENDER_THROTTLE_MS 50将 transcript 渲染上限限制在约 20fps与流式文本的实际可见变化速度匹配INPUT_QUIET_WINDOW_MS 100输入静默窗口期间若有输入则推迟渲染MAX_INPUT_DEFERRAL_MS 250输入推迟的上限避免因持续输入而永久饿死渲染。调度逻辑通过requestAnimationFrame实现当距上次通知不足 50ms、或存在即将到来的输入利用navigator.scheduling?.isInputPending?.()探测时不立即notify()而是继续请求下一帧直至满足条件或达到最大推迟上限const dispatchWhenDue (ts: number) { frame null; if ( ts - lastNotifyTs TRANSCRIPT_RENDER_THROTTLE_MS ((ts - lastInputTs INPUT_QUIET_WINDOW_MS !hasPendingInput()) || (pendingSinceTs ! null ts - pendingSinceTs MAX_INPUT_DEFERRAL_MS)) ) { lastNotifyTs ts; pendingSinceTs null; notify(); } else { frame window.requestAnimationFrame(dispatchWhenDue); } };同时hook 通过document.addEventListener(beforeinput, recordInput, true)记录输入时间戳并在卸载时正确清理订阅与动画帧避免泄漏。3.2 延迟快照session 身份 block-index 身份双重保护设计要点延迟defertranscript 快照并携带 session 与 block-index 身份。紧急的编辑器工作如用户正在打字可以基于上一个快照提交无需等待最新快照session 切换时旧 session 的延迟块被立即拒绝同一 session 内的 store 重置也会通过 block-index 身份立即拒绝陈旧的延迟块stale deferred blocks而不会阻塞普通的流式文本更新。源码中快照通过useSyncExternalStore订阅并用useMemo(() ({ sessionId, ...live }), [live, sessionId])将sessionId与实时快照绑定在一起// Session and block-index identities ride inside the deferred snapshot. The // session id rejects a previous session, while the index identity rejects a // same-session store reset without blocking ordinary streamed text updates. const snapshot useMemo(() ({ sessionId, ...live }), [live, sessionId]);在此基础上useDeferredValue保证流式渲染帧永远不会排在紧急更新输入、按钮点击之后实现「流式保持顺滑、打字保持响应」的双赢。3.3 WeakMap 保留归一化的工具内容引用为了让现有行比较器row comparator的 JSON 缓存发挥作用设计用WeakMap保存归一化后的工具内容normalized tool-content引用从而避免对未变化的历史工具输出进行重复序列化reserializing。这项设计的意义在于流式输出期间历史工具调用结果并没有变化若每次渲染都重新序列化比对成本会随历史长度线性增长借助WeakMap引用 JSON 缓存比较器可以快速判定「未变化」并跳过。3.4 保持 thinking 计时器存活流式内容 append 时thinking 的 elapsed 计时器必须保持存活keep alive而不是在每次内容追加时被重置或销毁。否则用户在长思考过程中会看到计时器反复归零且重复创建/销毁计时器本身也会带来额外开销。3.5 流式纯文本降级短响应保 Markdown长响应限成本这是对「Markdown 全量重解析」问题的直接回应短响应继续保持实时 Markdown渲染让已折叠的图表closed charts与普通格式ordinary formatting保持既有行为不变长响应一旦流式文档超过固定的解析预算fixed parse budget则将其节流后的源码渲染为保留空白符的转义纯文本escaped plain text with preserved whitespace流结束时一次性渲染完整 Markdown。这样既限制了重复解析的次数与成本又只推迟了大到足以引发问题的响应的格式化普通小响应的体验完全不受影响。3.6 投影身份复用仅尾部增长时复用历史推导最后一条设计针对MessageList的全量历史推导当所有历史 transcript block 均未变化且只有最后一个普通流式文本块在增长时保留投影后的历史对象身份identity不变在此窄条件下复用已完成历史的MessageList推导结果仅替换渲染的尾部行tail row任何更早 block 的变化、终端状态转换、工具/后台更新、usage 变化、翻译变化或视图选项变化都走原有全量计算路径。这条决策与第 3.1 节中的「tail-only 路径」共同构成了性能收益的主要来源——applyTurnCollapse、final-answer 收集、分组与显示索引生成等热点都因此从「全量重算」变为「只算增量」。四、Non-goals明确不做的事设计文档明确划定了边界避免过度设计不做通用的增量 transcript 投影器投影不是实测瓶颈窄化的 tail 路径避免了引入新的失效invalidation机制不做增量 Markdown AST也不引入 Web Worker纯文本流式渲染以更少的代码消除了重复解析且无需跨线程序列化cross-thread serialization不改 daemon 事件顺序、transcript 持久化或公开 block 结构所有优化都收敛在 Web Shell 客户端渲染层对外契约零变更。这些「不做什么」与「做什么」同样重要——它保证了优化方案的可落地性与可维护性。五、验证单元测试 Playwright 性能回归5.1 单元测试覆盖清单设计文档要求单元测试覆盖以下场景每项都对应一个具体的失效风险点通知合并notification coalescing多次 store 通知只触发一次渲染50ms 窗口渲染频率被正确节流取消cancellation卸载/切换时动画帧与订阅被正确清理session 切换旧 session 的延迟块被拒绝稳定的投影身份stable projection identity仅尾部增长时历史身份保持不变流式尾部渲染与失效streamed-tail rendering and invalidation尾部行的替换逻辑与失效条件稳定的工具归一化stable tool normalizationWeakMap 引用缓存行为计时器复用timer reusethinking elapsed 计时器跨 append 存活流式文本到稳定 Markdown 的转换streaming-text-to-settled-Markdown transition长响应降级为纯文本、流结束后恢复完整 Markdown 渲染。这些场景在仓库中对应 packages/web-shell/client/hooks/useAnimationFrameTranscriptBlocks.test.tsx节流与调度、packages/web-shell/client/components/MessageList.test.ts 与 MessageList.dom.test.tsx投影、turnCollapse 与 DOM 行为等测试文件中均有实现。5.2 Playwright 性能端到端测试设计文档规定通过 Web Shell 工作区的性能测试命令进行确定性回归验证npm run test:e2e:perf --workspaceqwen-code/web-shell该命令在 packages/web-shell/package.json 中的真实定义为test:e2e:perf: cross-env WEB_SHELL_PERF1 playwright test --config playwright.config.ts --grep perf --projectchromium它通过WEB_SHELL_PERF1环境变量启用性能模式用--grep perf只筛选性能测试用例并在 chromium 项目中运行。测试内容为确定性回放 5,000 个历史轮次historical turns边打字边流式灌入 400 个 Markdown 密集型 chunkMarkdown-heavy chunks校验最终输出与 composer 内容的正确性在 Playwright 报告中记录输入延迟input latency与浏览器长任务long-task指标。该测试同时覆盖「正确性」与「性能」两个维度内容必须与预期一致同时输入延迟与长任务指标必须达标二者缺一不可。六、源码阅读路线图如果你希望深入代码验证上述设计推荐按以下路径阅读节流与延迟快照packages/web-shell/client/hooks/useAnimationFrameTranscriptBlocks.ts —— 三个时间常量、isInputPending探测、rAF 调度与useDeferredValue投影热点packages/web-shell/client/components/MessageList.tsx ——applyTurnCollapse的定义约第 1872 行与调用点约第 3657 行以及TurnCollapseHead类型与折叠行的渲染逻辑身份复用MessageList.tsx中基于blockChangeSummary.source与tailAppendBarrierRevision的结构相等性判断对应 hook 中的isSameTranscriptStructure性能回归入口packages/web-shell/package.json 中的test:e2e:perf脚本。七、经验总结从本设计可迁移的方法论这篇设计文档虽然针对 qwen-code 的 Web Shell但其优化思路具有普适性先剖析再优化用 profiling 数据说话——投影只占 2.5%却差点被当成优化重点真正的热点在applyTurnCollapse与全量推导按可见性定价渲染频率文本 80ms 节流、transcript 50ms 节流、事件 16ms 批处理渲染频率与人类可感知的变化速度匹配即可不必追求 60fps给紧急工作让路isInputPending 延迟快照 最大推迟上限让编辑器输入永远不被流式渲染排队阻塞用身份而非内容做缓存WeakMap引用 block/session 身份 投影对象身份复用用「不变则跳过」替代「全量重算」明确 Non-goals不做通用增量投影器、不做 Worker、不改 daemon 契约控制方案复杂度保证可维护性正确性与性能一起验证Playwright 既校验最终输出与 composer 内容又记录输入延迟与长任务指标防止「优化了性能、破坏了功能」。如果当前项目同样面临「长会话 流式输出导致主线程卡顿」的问题本文的六项措施与验证思路可以直接作为设计与验收的参考蓝本。【免费下载链接】qwen-codeAn open-source AI coding agent that lives in your terminal.项目地址: https://gitcode.com/GitHub_Trending/qw/qwen-code创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考