[建议/Web体验] 建议优先保证前端流畅度而非 hidden="until-found"：折叠工具与思考时真正卸载 DOM，解决长会话严重卡顿

[Erick0412-dev]

注：本优化想法与实测由 @Erick0412-dev 提出，具体技术分析与文案由 AI 协助排版整理。

问题背景

在当前 DSH（包括最新的 0.1.5-rc.1 与 master 分支）的 Web 前端实现中，长会话或多工具调用的复杂 Agent 任务经常出现极其严重的卡顿：打字延迟高达数秒、页面滚动掉帧、浏览器内存暴涨甚至标签页假死。

深入排查后，我们发现前端性能瓶颈主要来自目前 @deepseek-ai/dsh-client-ui-chat 的折叠与历史机制：

1. hidden="until-found" 导致的常驻 DOM 节点爆炸：
   在官方设计决策（2026-08-14-web-turn-process-folding）中记录到：

   “复用 DisclosureRow 并卸载收起成员。不采用：浏览器查找无法发现其文本，重新打开也会重建有状态 renderer 子树。”
   “隐藏的 wrapper 与 Markdown 子树保持挂载，用一定浏览器内存换取稳定工具状态、跨视图重挂载的手动展开状态与浏览器查找恢复。”

   因此，目前代码中折叠仅是切换 hidden="until-found" 属性，收起部分的所有复杂 Markdown、代码高亮、成千上万行终端输出依然全量挂载在 DOM 树中（长任务单会话 DOM 常达 17,000+）。每当模型流式生成一个 token，Chromium 主线程都要进行整树的重排计算（Layout Thrashing），引发主线程假死。

2. !historyIncomplete 导致长会话的折叠全盘失效：
   在 ChatNodeSeat.tsx 中，processWindowReady 硬编码了必须满足 !historyIncomplete（对应 ChatView 中的 hasMore）。
   这导致只要用户没有一路点击“加载更早”把历史拉到第一轮，整场会话的所有轮次完全不进行任何折叠，原本就庞大的中间过程被迫全部以全高形态铺在页面上，直接将卡顿推向极限。

---

现实痛点：Ctrl+F 搜折叠内容真的值得牺牲流畅度吗？

我们非常理解官方当初采用这套设计时的初衷：

• 利用浏览器原生的 hidden="until-found" 与 beforematch 规范，让用户用 Ctrl+F 检索时能自动展开折叠内容；
• 避免频繁收起/展开时重建有状态的复杂组件（如 Terminal/Diff 视图）；
• 避免在历史片段未完全加载时折叠带来潜在的布局重排（CLS）。

但是，在现实开发者的真实使用场景中，这一取舍产生了严重的体验失衡：

• 极少有用户会用浏览器的 Ctrl+F 去翻找 20 分钟前一段已经执行完毕的长篇终端输出或折叠报错。
• 如果用户真有跨轮次全文检索的需求，完全可以通过专用的搜索面板/检索插件（在内存或后台日志中进行索引和高亮）来优雅解决，根本不需要让浏览器的主 DOM 树来当这个“搜索索引的代价承担者”。
• 界面的即时顺滑（打字零延迟、滚动跟手）是用户每一秒都在消耗的核心生命线。为了兼顾一个低频的页内搜索规范和有状态缓存，让整个界面在长会话中退化到“不可用”的状态，有些得不偿失。

---

本地实测对比（修改为真卸载 DOM）

我们在本地对 @deepseek-ai/dsh-client-ui-chat 进行了简易热补丁验证：

1. 折叠时真卸载：当 processHidden 为真时，直接不渲染内部节点（children: processHidden ? null : renderSlot(...)），深度思考块同理。
2. 解绑分页：移除 && !historyIncomplete 判定，让已结算的已关闭轮次无论前驱历史是否完整，都能正常进入收起状态。

实测效果提升极其惊人：

• 页面常驻 DOM 节点数从 17,000+ 暴降至数百个。
• 浏览器内存占用下降超过 70%。
• 即使在多达 50+ 个 step、几十次工具调用的长任务中，输入框打字完全恢复零延迟，列表滚动丝般顺滑。
• 代价：仅仅是展开那一瞬间会有几毫秒的重新渲染，且原生 Ctrl+F 搜不到收起内容——所有实测开发者一致认为这个取舍对于日常编码体验是绝对利大于弊的。

---

建议解决方案

1. 短期建议（下放偏好设置项）：
   在 Settings -> General 中增加轻量化开关，允许用户自主选择折叠策略（例如：性能优先（卸载DOM） vs 原生搜索（保留DOM）），并允许长会话在未拉取完前序历史时也正常启用折叠。
2. 长期建议（虚拟滚动）：
   探讨在 ChatView 中引入真正的虚拟滚动（Virtual List），彻底摆脱长对话下对全量 DOM 挂载的依赖。