【BUG】dsh web GUI 内存泄漏问题报告

[baosfeng]

---

一、问题概述

dsh web 前端在长时间、持续流式输出的会话中，页面渲染进程内存单向累积，实测 5 小时后达到 9.4G 物理占用（峰值 13.7G），并伴随渲染进程主线程长期 100% 占用、GC 抖动。刷新页面可回收内存，说明是页面侧堆累积，而非服务端。

同一台机器上，dsh 服务端（node 进程）占用仅 426MB 且平稳，问题完全位于前端页面。

---

二、环境

项	值
dsh 版本	0.1.5-rc.1（dsh web --port 6010 --no-open）
OS	macOS 26.6.2 (25G83)
WebKit	21624.5.1.11.3（WKWebView 承载，Tauri 2 壳）
页面	http://127.0.0.1:6010/（dsh web GUI）
事发会话时长	5 小时 11 分（进程 14:16 启动，19:27 采样）

---

三、取样证据（/usr/bin/sample，2251 样本 × 1ms ≈ 2.25s 窗口）

采样头部：

Physical footprint:         9.4G
Physical footprint (peak):  13.7G

3.1 主线程全程 100% 忙，且 86.8% 落在「处理 WebSocket 流式消息」这条链上

WebSocket::didReceiveMessage                     ← 1953 / 2251 样本
  → WebCore::EventTarget::dispatchEvent
  → WebCore::JSEventListener::handleEvent
  → WebCore::MicrotaskQueue::performMicrotaskCheckpoint
  → JSC::callMicrotask → <JIT JS>

3.2 JIT JS 内部：疯狂分配对象 + 反复 GC（堆大且几乎全是存活对象）

符号	样本数	含义
JSC::LocalAllocator::allocateSlowCase	481	分配走慢路径（堆压力大）
JSC::JSFinalObject::visitChildren	267	GC 扫描对象
JSC::MarkedBlock::Handle::sweep	107	GC 清扫
JSC::JSCellButterfly::visitChildren	97	GC 扫描
madvise	87	bmalloc 归还/整理内存页
JSC::JSObject::visitChildren	67	GC 扫描
JSC::SlotVisitor::drain	48	GC 标记
JSC::IncrementalSweeper::doSweep	24	增量清扫
JSC::EdenGCActivityCallback::gcTimeSlice	9	新生代 GC 时间片
WTF::WeakHashSet<WebCore::EventLoopTaskGroup>::add	66	任务组被大量创建（定时器/任务密集）

对比：布局/绘制仅约 2%（WebCore::RenderBlock::paint 递归计数 44）。CPU 主要烧在 JS 对象分配与 GC 上。

3.3 疑似不可变状态「整树复制 + 冻结」痕迹

调用链中出现：

• JSC::globalFuncCopyDataProperties（对象展开/Object.assign 式浅拷贝）
• JSC::objectConstructorIsFrozen / JSC::objectConstructorFreeze（递归冻结）
• JSC::JSObject::getOwnPropertyNames / JSC::Structure::getPropertyNamesFromStructure
• JSC::JSObject::putOwnDataPropertyBatching

即每条流式事件都可能在整棵会话状态树上做一遍拷贝 + 冻结，成本随会话增长而增长。

---

四、复现（现场实测，非推测）

同一环境、全新启动的应用，仅持续一个正常会话（对话流式输出）：

时刻        GUI 页面渲染进程物理占用
19:36:34      281.5 MB
19:36:49      318.7 MB
19:37:04      361.6 MB
19:37:19      374.2 MB
19:38:04      369.8 MB     ← GC 回收了一部分
19:38:19      554.0 MB     ← 一段较长工具输出渲染
19:38:34      632.9 MB
19:38:49      455.2 MB     ← 部分回收，但基线已抬高
19:39:04      454.0 MB

• 活跃对话期间基线约 +70MB/分钟，GC 只能削掉一部分，基线持续抬升；
• 照此速率 5 小时量级正好落到 GB 级，与取样观察到的 9.4G 吻合；
• 页面刚打开、加载既有会话历史时，45 秒内即从 281MB 涨到 374MB → 渲染既有会话历史本身也是大头，长会话 + 大量长工具输出会显著放大。

复现要点：一个包含大量长工具输出（数十 KBMB 级文本）的会话，持续流式对话 1030 分钟即可稳定观察到渲染进程内存单向抬升。

---

五、怀疑方向（供上游定位参考）

1. 会话/事件数据无上限驻留：渲染进程持有整段会话（含所有工具输出原文）及其派生结构，长会话下线性甚至超线性增长。
2. 每条流式事件对全量状态做拷贝/冻结：取样中的 copyDataProperties + freeze + getOwnPropertyNames 组合与之吻合；事件频率高（每秒数百条 WS 消息）× 状态树大 → 分配量与 GC 压力随会话增长。
3. 渲染层未做窗口化/截断：超长工具输出若整段进入 DOM/虚拟树并常驻，内存与后续每次重渲染成本都会被放大。
4. WebKit 侧内存不归还：堆反复增长-回收后 footprint 基线抬升，疑与 JSC/bmalloc 页回收策略叠加（此点需上游前端先行降低堆峰值后再评估）。

---

六、影响

• 单页面渲染进程可达 9~14G，长时间使用后整机内存吃紧、系统卡顿；
• 主线程被 WS 处理与 GC 占满，界面响应变差；
• 对「长时间挂着跑任务」的典型用法（数小时会话）影响尤其明显。

---

七、期望

• 会话事件/工具输出在内存中有明确上限（分页、截断、按需拉取、离开视口即释放）；
• 流式事件的状态更新避免对全量状态做拷贝/冻结（选择性更新）；
• 长会话下内存曲线应平稳收敛而非单向累积；页面提供内存可回收的机制（如卸载不可见长历史）。

---

八、附件

• “JF-Harness Web Content”的取样.txt：sample 原始输出（9.4G 现场，pid 78054）。

[Robin1987China]

这份取样很有价值 —— sample 的调用栈把范围锁死在页面侧，和你的判断一致。
我做了源码侧核查，补一个结构性结论，也把我没有验证的部分说清楚。

页面侧常驻内存没有淘汰路径

客户端对会话转录只做追加，没有任何淘汰：

• packages/client/ui-chat/src/client/chat/ChatView.tsx:242 — hasMore 来自会话状态
• ChatView.tsx:777-789 — 只渲染「加载更早」按钮，并把它透传给 ChatNodeSeat
• 我在整个 packages/client（排除 tests/fixture）下搜
  evict | prune | dropOlder | releaseNodes | maxRetain | trimHistory | splice(0 | slice(-
  —— 唯一命中是 modules/src/client/system.ts:105（模块加载队列），与转录无关。
• loadOlder 的唯一实现（ui-conversation/src/client/service.ts:514）只是取更早的页
  并追加。

也就是说：每一页加载过的历史、以及每一条流式事件提交进转录的节点，都会一直留在
页面堆里直到刷新。这与你观察到的「刷新即回收、服务端 426MB 平稳」完全吻合。

一个会把情况放大的交互

#6325（思考过程无法折叠）的现有社区方案 dsh-auto-fold，是在 Compact 模式下调用
session.loadThrough(0) 把全部历史拉进页面，从而清掉 hasMore、恢复原生折叠。
这条路径会主动把整段会话驻留到页面内存，因此会加剧本问题的表现。

我没有做的，以及为什么

我没有在真实浏览器里复现这次泄漏，因此不会声称定位到了某个确定的泄漏点。
WebSocket::didReceiveMessage → dispatchEvent → JSEventListener::handleEvent → MicrotaskQueue::performMicrotask 占 86.8% 只能说明主线程几乎都在处理消息投递与
微任务，它本身不足以区分「消息量大」与「保留结构无界增长」——两者都会长这样。

要定位到可修复的点，建议下一步这样测（能直接区分两类原因）：

1. 打开同一会话，在 DevTools 里做两次 Heap Snapshot，中间持续流式输出 10 分钟，
   比较 Retained Size 的增长落在哪类对象上（DOM 节点 / React fiber / 事件数组 /
   字符串）。
2. 同时跑 Performance 录制，确认单条消息的处理耗时是否随历史长度增长。
   若近似线性增长，问题是每条消息全量重算；若不随长度变化而只是堆涨，
   问题是只增不淘汰。

修复落点方向

无论上面是哪一类，落点都在客户端转录的驻留策略上：给已加载窗口加淘汰
（例如只保留可视区附近的节点，滚动时按需回填），这是客户端架构变更，不是插件能
覆盖的。插件只能改行为，改不了客户端的保留策略。

如果你愿意把两份 Heap Snapshot 的对比贴出来，我可以帮着定位到具体对象。