[0.2.1-rc.2] 用着用着就卡死

[shubingdev]

不知道是不是因为会话多了，每次启动后没用多久就卡死了，会话加载不出来，新建会话点击没反应，此时黑框控制台没有报错，重启dsh后就恢复了，不过没用多久又会这样，归档一些会话后正常的时间会长一些，我现在每个工作区已经只留下必要的几个会话了，还是经常会出现这种情况，之前 0.1.x 的版本好像没遇到过

[shubingdev]

我让AI帮我排查了，是我装的一个插件导致的

[liukjx]

同类现象，补一份独立复现的数据（Windows 11 / 0.2.1-rc.2）：

• 旧实例 19:32 启动 → 23:00:38 进 Modern Standby → 00:28:26 唤醒 → 00:29:27–00:29:34 的 7 秒内连续建了 5 个会话，其中 3 个 createdAt 是同一毫秒 1793291374606；从第一次点击到 00:35:09 重启，中间 5 分 42 秒没有任何可见响应。
• 卡住时新建的会话在磁盘上是 317–321 B 的 header-only（解压后 192 B，只有 header、isSeeded:false）——宿主建出来了，UI 没切过去，所以和你的「新建会话点击没反应」是同一件事。
• 排除磁盘/内存：219 个会话头全读 328 ms、projcache 4.6 MB 加载 52–58 ms、58,855 个文件的目录全量遍历 1.16 s；64 GB 内存空闲 30 GB，10 分钟内 4 次采样宿主 WS/句柄没有单调增长。

顺着 0.2.1-rc.2 的代码找到了「为什么越用越慢」的累积机制：每个打开过的会话都会被 follow → promote 成常驻 live Agent（RPC 面没有 session/close，拆除只绑在宿主根 ctx），每个 Agent 又挂一套 skill-filesystem 的 watchFile(100ms) + chokidar，新建会话还会必然重扫全部技能；再加上 cordis 单表 O(n) 事件分发和 renderer 列表 O(n) 重建。相处的时间越长，新建会话这条链路越慢，睡眠唤醒后就会一次性卡死。

完整证据、行号和修复建议写在 #11479。所以它大概率不是某个插件造成的——插件只是放大器（我这台机器上桌宠另起一整套 Electron、约 +16% 单核，壁纸插件让 GPU 常驻 100%+）。

临时能做的：①少点开旧会话、用完归档；②睡眠前退出 DSH；③在 ptc preset 里给 skill-filesystem 加 { watch: false }（代价是技能文件改动不再热更新）。