[Bug] 对话特别长时，流式渲染出现极其严重的延迟

[Fronut]

What happened / 发生了什么

Tauri 桌面端在对话特别长时，流式渲染出现严重延迟。后端已在 5 分钟内完成生成，但前端持续渲染 10+ 分钟才显示完毕。在此期间：

• 日志显示 SSE 流早已结束
• 页面仍显示流式动画（进度条旋转），文字缓慢增长
• 右键刷新页面 → 立即显示完整回答（因为走了非流式一次性渲染路径）
• 浏览器直接连接后端 → 流式渲染仍旧有延迟但相比桌面端略轻

Reproduce / 如何复现？

1. 在 Tauri 桌面端发起一次长对话（回复内容数万字符，含 markdown）
2. 等待后端生成完毕（约 5 分钟）
3. 观察前端——流式渲染持续远超实际生成时间（10+ 分钟）

根因分析

问题出在 dashboard/src/components/chat/message_list_comps/MarkdownMessagePart.vue 中 max-live-nodes="0"：

<MarkdownRender
  :content="content"
  :final="!isStreaming"
  :smooth-streaming="isStreaming ? 'auto' : false"
  :fade="false"
  :typewriter="false"
  :max-live-nodes="0"    ⬅ 问题所在
/>

markstream-vue 的 MarkdownRender 组件默认 maxLiveNodes=320，这里显式设为 0（无上限）。

为什么会导致延迟雪崩？

流式模式下（final=false），每个 SSE chunk 到达时触发：

SSE chunk → appendPlain() 修改 record.content.message[last].text
  → Vue 响应式更新 → content prop 变化
    → MarkdownRender 重新解析整段 Markdown（O(n) 每次）
      → 所有 DOM 节点全部保留（max-live-nodes=0，无回收）
        → DOM 树持续膨胀（数千节点）
          → 每个 chunk 的重渲染成本递增（O(n²) 效应）

浏览器上 max-live-nodes=0 带来的 O(n²) 效应勉强可承受，WebView2 的 DOM 操作更慢，导致渲染速度追不上数据到达速度，形成积压雪崩。

为什么刷新后瞬间显示？

刷新后走历史消息加载路径，isStreaming=false → final=true → MarkdownRender 一次性渲染最终内容，无增量重解析开销。

AstrBot version, deployment method (e.g., Windows Docker Desktop deployment), provider used, and messaging platform used. / AstrBot 版本、部署方式（如 Windows Docker Desktop 部署）、使用的提供商、使用的消息平台适配器

4.26.2 Desktop

OS

Windows

Logs / 报错日志

这是一个已经有650多轮的对话，现在我们发送了一个问题在tauri桌面端。
我们可以看到在17:16:39的时候后端已经提示了对话结束（那个记忆插件在对话结束后触发）这个是网页端连接的后端

而此时在Tauri桌面端这边还在慢悠悠有着巨大延迟地转（这个对话一共调用了16个工具，但桌面端竟然提示才到第五个），此时已经是17:18:02

然后我们在浏览器手动打开前端找到这个聊天，我们发现确实是已经结束了，此时是17:19:56

再看一眼桌面端，没错他还在慢悠悠地停留在第五个工具调用，此时是17:20:33

桌面端直到17:22:37的时候，这16个工具调用才算是渲染完了，这还在慢慢渲染对话

最终在17:23:32的时候，桌面端终于完成了渲染

在这个例子当中，从后端实际完成到前端显示完成，中间足足过去了七分钟！有一种拨号上网加载199X年的网页的感觉......

Are you willing to submit a PR? / 你愿意提交 PR 吗？

• Yes!

Code of Conduct

• I have read and agree to abide by the project's Code of Conduct。

[dosubot]

感谢这份详细的根因分析！你对 max-live-nodes="0" 导致 O(n²) 渲染雪崩的判断非常准确。

确认一下代码现状：MarkdownMessagePart.vue 中确实将 max-live-nodes 显式设为 0（无上限）[1]，而 markstream-vue 默认值为 320。在超长对话（650+ 轮、数万字符）的场景下，WebView2 的 DOM 操作性能瓶颈会被这个设置急剧放大。

这个文件是在 PR #8371 中配置的（2026 年 5 月合并），当时将 markstream-vue 从 0.0.6 升级到 1.0.1-beta.1 并启用了 smooth streaming [2]。max-live-nodes=0 可能是为了避免截断显示而设置的，但在超长内容场景下副作用严重。

修复方向建议：

• 将 max-live-nodes 恢复为合理值（如默认 320 或根据实际测试调整）
• 或者根据内容长度动态设置该值（短内容可以无限制，长内容启用回收）

期待你的 PR！

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[Fronut]

PR #8371 带来了超长内容下面的超高延迟的问题，这是一个糟糕的副作用，这有待解决
@Soulter @Simon-He95

[Simon-He95]

PR #8371 带来了超长内容下面的超高延迟的问题，这是一个糟糕的副作用，这有待解决 @Soulter @Simon-He95

可以试一下把stream-markdown和markstream-vue升级到最新版本试试