[Bug] WebView 渲染进程 MutationObserver 微任务死循环导致 UI 完全卡死（CPU 100%），归档会话后恢复

[baosfeng]

---

环境

项目	值
OS	macOS 26.5.2 (25F84)，Apple Silicon (arm64)
dsh	0.1.1-rc.2（@deepseek-ai/dsh，npm 全局安装）
Node	v26.7.0
外壳	DeepSeek Harness 桌面应用（Tauri 2 + WKWebView）
WebKit	21624 (21624.2.5.11.8)

现象

dsh web 页面完全卡死（无法点击、无法滚动、无法输入），com.apple.WebKit.WebContent 渲染进程 CPU 持续 95%+，物理内存 ~600-720MB。sample 采样（1ms 间隔，2300+ 次）显示主线程 100% 时间卡在 MutationObserver 微任务循环，无一次空闲采样。

核心调用栈（来自 sample 日志）

Thread_13057885  com.apple.main-thread（2311/2311 次采样全部命中）
└─ timerFired → WindowEventLoop::didReachTimeToRun
   └─ MicrotaskQueue::performMicrotaskCheckpoint
      └─ queueMutationObserverCompoundMicrotask
         └─ MutationObserver::notifyMutationObservers（2306 次）
            └─ MutationObserver::deliver（2296 次）
               └─ JSMutationCallback::invoke（2268 次）
                  └─ JSCallbackData::invokeCallback → JS 回调（JIT 代码）
                     ├─ jsDocumentPrototypeFunction_querySelectorAll（1853 次）
                     │  └─ SelectorDataList::execute（1337 次，选择器匹配执行）
                     ├─ setJSNode_nodeValue → setDataAndUpdate（124 次，修改文本节点）
                     │  └─ dispatchModifiedEvent → enqueueMutationRecord（再次入队！）
                     ├─ jsElementPrototypeFunction_hasAttribute（36 次）
                     ├─ jsElement_className / jsNode_nodeName / parentElement / trim（密集 DOM 遍历）
                     └─ regExpProtoFuncTest / stringProtoFuncStartsWith（字符串处理）

循环机制：JS 回调每次执行 document.querySelectorAll 全文档扫描 + 修改文本节点（setNodeValue），修改产生新的 mutation 记录（enqueueMutationRecord）→ 微任务 checkpoint 再次触发回调 → 无限循环，主线程被占满。

其他线程（libpas scavenger、Heap Helper、workqueue）全部正常等待（__psynch_cvwait），不是死锁，是纯 CPU 忙循环。

关键排查过程

步骤	操作	结果
1	禁用全部注入型插件（tool-i18n、statusbar-cn、think-expand、reasonix-memory 等 4 个 MutationObserver 插件，cordis.patch.yml 全部 disabled: true，页面 HTML 确认无任何注入脚本）	❌ 循环依旧
2	清空 WebKit NetworkCache / CacheStorage	❌ 循环依旧
3	重启应用、kill 渲染进程（新进程同样卡死）	❌ 循环依旧
4	归档某个项目的全部会话（~/.dsh/sessions/<project>/ 移到 sessions-archive/）	✅ 立即恢复，CPU 归零，页面流畅

结论

循环由特定会话内容触发，与插件无关。某个项目的会话（18 个会话全部归档后恢复）在渲染时触发前端 MutationObserver 反馈循环：React 重渲染 → DOM 变化 → 前端 observer 回调（querySelectorAll + 文本修改）→ 再次触发渲染 → 无限循环。

复现线索

• 卡死发生在打开/切换到特定项目会话时；归档该项目全部会话后立即恢复
• 循环栈中 setNodeValue 修改的是文本节点，回调里同时有 hasAttribute/className/nodeName/parentElement/trim 等密集 DOM 遍历操作
• 物理内存 600-720MB，DOM 规模较大（怀疑超长上下文或特殊内容触发）
• 已确认与 npm 依赖解析卡死（[Bug] npx @deepseek-ai/dsh web 无限卡死：npm 依赖解析死循环（CPU 100%、零网络流量、换镜像无效） #3786）无关，是运行期渲染问题

建议

1. 排查前端 MutationObserver 回调对自己修改的文本再次匹配的反馈路径（翻译/格式化类逻辑），增加防重入/熔断机制
2. 排查会话渲染路径：超长上下文或特定内容是否触发 React 重渲染风暴
3. 建议提供"会话级熔断"或"渲染超时保护"，避免单个会话拖死整个 UI
4. 建议提供会话数据导出/诊断工具，便于用户上报问题会话

附件说明

• test.txt：/usr/bin/sample 采样日志（pid 60594，16:14 采样，1295 行），包含完整调用栈、热点统计、二进制镜像信息，可直接上传到讨论帖作为证据

[baosfeng]

test.txt
这个是 dump 日志

[denial123789]

这个 sample 很有价值：它能证明 WebContent 主线程持续在交付 MutationObserver 回调，并且回调包含全文档选择与文本写入；但 native 栈还不能识别是谁注册了 observer，也不能仅凭“归档项目会话后恢复”确定某个 Session 或 DSH React 核心就是根因。

我对 0.1.1-rc.2 的 b150a55 做了源码边界核对：官方仓库 apps/ 只有 cli 和 web，不包含这里使用的 Tauri 桌面外壳；受版本控制的生产源码中也没有一方 MutationObserver 注册，命中项是 Web 性能/E2E 测试探针。这个结果不能排除 bundle 依赖、动态 client plugin、桌面 preload 或不同构建 artifact，但说明需要先获取 observer 的注册栈，不能从 WebKit 的 deliver 栈直接归因。

建议最小化时保持同一份离线复制的 profile、同一 DSH artifact 和同一 Session，只改变一个平面：

1. 独立干净浏览器打开官方 dsh web，与桌面 WebView 做 shell A/B；
2. 记录页面实际加载的 script/module URL 与 digest，确认所谓“禁用”脚本确实没有加载/执行；
3. 在一次性客户端里、加载问题 Session 之前包装 MutationObserver 构造函数并 console.trace，取得注册脚本、observed root 和 options；
4. 统计每帧 mutation batch/record、selector scan 和 DOM write，确认 callback 的写入是否落在自己的 observed subtree；
5. 只在完整 profile 快照的副本上隔离 Session。官方 archive 是非破坏性的可见性操作，但 rc.2 没有对应 unarchive，不适合作为反复二分开关；
6. 找到单个 Session 后，缩减脱敏的 export fixture，不编辑、重排或合并权威 JSONL。分别测试内容形状和规模。

修复门禁应包含：写前比较 old/desired value、忽略自己生成的节点、缩小 observed root、dispose/session switch 时 disconnect、每帧/每秒扫描和写入上限，以及能保留导航的 session-level circuit breaker。

完整采集字段、构造栈探针、隐私边界和 16 项回归门禁整理在：
https://sandbaseai.github.io/deepseek-harness-handbook/webview-mutation-loop.html

这是社区维护的源码分析，不代表官方已经确认根因。