next drawio界面卡死问题分析

浏览器弹出「页面无响应」或长时间转圈，本质是 主线程被同步任务占满超过几秒。在这个项目里，大模型请求期间有几条路径会叠加阻塞，下面按影响和改法说明。

---

卡死从哪里来

1. 流式更新图表（最大瓶颈）

AI 生成 display_diagram 时，XML 会不断流式推送。chat-message-display.tsx 里大约每 150ms 触发一次图表更新：

    const STREAMING_DEBOUNCE_MS = 150 // Keep original 150ms debounce timing

每次 handleDisplayChart 会在主线程同步执行：

• DOMParser 解析 XML（多次）
• replaceNodes 合并节点（又一次 DOM 解析/序列化）
• validateAndFixXml → validateMxCellStructure（DOM + 大量正则）
• loadDiagram → drawioRef.load() 重载 iframe 内容

    const handleDisplayChart = useCallback(
        (xml: string, showToast = false) => {
            // ... DOMParser → replaceNodes → validateAndFixXml → onDisplayChart

        setChartXML(xmlToLoad)
        if (drawioRef.current) {
            drawioRef.current.load({
                xml: xmlToLoad,
            })

Draw.io iframe 的 load() 非常重，流式阶段若每秒多次调用，很容易触发浏览器「页面无响应」弹框。

2. 每条流式 token 触发整页 React 重渲染

useChat 每次收到数据都会更新 messages，导致：

• ChatMessageDisplay 整棵消息树 messages.map 重渲染
• useEffect([messages, handleDisplayChart]) 再次执行
• ReactMarkdown 反复解析正在增长的文本

    }, [messages, handleDisplayChart])

3. localStorage 同步写入

对话和 XML 会 debounce 1 秒后 JSON.stringify 写入 localStorage，流式期间若消息/XML 很大，写入会短暂阻塞主线程：

    useEffect(() => {
        // ...
        localStorageDebounceRef.current = setTimeout(() => {
            localStorage.setItem(
                STORAGE_MESSAGES_KEY,
                JSON.stringify(messages),
            )
        }, LOCAL_STORAGE_DEBOUNCE_MS)

4. 开发模式下的日志开销

validateMxCellStructure 在热路径上有大量 console.time / console.log，开发模式下会明显拖慢：

    console.time("perf:validateMxCellStructure")
    console.log(`perf:validateMxCellStructure XML size: ${xml.length} bytes`)

---

优化方向（按收益排序）

方案 A：流式阶段不实时刷新 Draw.io（收益最大，改动相对小）

思路 ：input-streaming / input-available 时只显示「生成中」占位，仅在 output-available（最终 XML）时调用一次 loadDiagram。

当前逻辑在流式阶段就会 debounce 更新图表（约 520--551 行）。可改为：

• 流式：只更新聊天区里的预览文本/进度条
• 完成：再执行一次完整的校验 + loadDiagram

这样通常能消除大部分假死，代价是生成过程中右侧画布不「逐帧」更新。

方案 B：加大 debounce，并合并更新

若仍要流式预览：

• 将 STREAMING_DEBOUNCE_MS 从 150 → 500～1000ms
• 用 requestIdleCallback（带 setTimeout fallback）把 handleDisplayChart 放到空闲时段执行
• 流式阶段跳过 validateAndFixXml，只做轻量「能否 parse」检查；完整校验留给最终一次

方案 C：减少 React 重渲染

• 用 React.memo 包裹单条 Message，流式时只让最后一条 assistant 消息重渲染
• 对 messages 使用 useDeferredValue，让输入和滚动优先
• 流式文本用简单 <pre> 或节流后的 Markdown，结束后再渲染完整 Markdown

方案 D：把 XML 处理移出主线程

• 用 Web Worker 跑 replaceNodes、validateAndFixXml（或至少 validateMxCellStructure）
• 主线程只负责把 Worker 返回的最终 XML 交给 loadDiagram

适合复杂大图，实现成本较高，但能从根上避免长同步任务。

方案 E：优化存储策略

• status === 'streaming' 期间不写 localStorage
• 仅在请求结束或用户空闲时保存
• 大 XML 用 IndexedDB，或只存摘要/最近 N 条消息

方案 F：生产环境去掉热路径日志

• validateMxCellStructure、handleDisplayChart 等处的 console.time / console.log 用 if (DEBUG) 包裹，或仅在开发环境启用

开发模式下卡顿会比生产更明显。

---

推荐实施顺序

优先级	改动	预期效果
P0	流式阶段不调用 drawioRef.load()，仅最终更新一次	假死弹框基本可消除
P1	消息列表按需渲染 + useDeferredValue	聊天区滚动/输入更顺滑
P2	流式期间暂停 localStorage 写入	减少周期性卡顿
P3	Worker 处理 XML 校验	复杂图仍流畅
P4	去掉生产环境热路径日志	开发体验改善

---

用户侧临时缓解（不改代码）

• 生成复杂图时尽量别频繁操作界面
• 定期清空长对话和 localStorage 缓存
• 用 npm run build && npm run start 测生产构建（比 dev + Turbopack 轻很多）
• 关闭其他标签页，减轻 Draw.io iframe 竞争

---

如何验证优化是否有效

Chrome DevTools → Performance 录制一次完整生成流程，关注：

• 长条 Scripting（同步 JS）
• validateMxCellStructure、loadDiagram、JSON.stringify 是否占主导

若长任务集中在 drawioRef.load 和 XML 校验，优先做 方案 A + B。