[Bug]: Mac客户端非常卡

[July-X]

Version line

v2 — Go rewrite (1.x), main-v2 (active development)

Exact version

1.8.0

What happened?

挂一段时间后，就会很卡，新版本能报告了，目前只能靠重启App解决。希望大佬能早日优化一下

Steps to reproduce

Mac App启动后对话，然后挂起就会卡，切换对话很明显

OS / platform

macOS 26.5.1 (25F80)

Relevant logs or output

[GTC2080]

已确认这个报告是真实存在的：v1.8.0 的性能提示里记录到了接近 1.9s 的 event-loop lag，而且切换会话变慢的现象与历史恢复路径的开销一致。

根因主要不在性能提示本身，而是在恢复/切换历史会话时，后端仍会把完整的历史工具参数和成功输出一次性通过 Wails bridge 发给前端；前端再归档这些数据，所以常驻内存能降下来，但切换时仍要承担大 JSON 传输和同步转换成本。

已提交修复 PR：#4443

修复会让历史恢复初始 payload 只包含折叠工具卡需要的 subject/summary 和归档标记，完整工具数据只在展开当前活动会话的工具卡时按需加载；同时保留 todo_write 和旧会话里没有 tool id 的 payload，避免影响任务面板恢复和历史兼容性。相关 Go/前端回归测试和构建验证也已经补齐。

[July-X]

[performance.lag]

UI responsiveness degraded because the app observed long tasks, event-loop lag, or high JS heap pressure.

--- performance context ---
reason: event loop lag 1490ms
uptime: 1556.2s
visibility: visible
focused: true
online: true
hardware concurrency: 8
event loop lag: current 1490ms, max 1490ms, avg 67ms over 58 samples

--- breadcrumbs ---
-1555.8s [app] start
-1555.5s [view] visible
-1555.1s [bridge] turn ReplayPendingPrompts
-1553.1s [bridge] update CheckUpdate
-1553.1s [bridge] turn ReplayPendingPrompts
-1139.1s [bridge] nav OpenGlobalTab
-1138.9s [bridge] turn ReplayPendingPrompts
-1126.1s [bridge] nav EnsureBlankTab
-1125.9s [bridge] turn ReplayPendingPrompts
-1114.3s [bridge] nav OpenProjectTab
-1114.2s [bridge] turn ReplayPendingPrompts
-912.3s [bridge] model SetEffortForTab
-909.1s [bridge] model SetEffortForTab
-907.5s [bridge] turn SubmitDisplayToTab
-506.0s [bridge] turn SubmitToTab
-0.0s [performance] event loop lag 1490ms

build a029618

[July-X]

还需要看看webkit渲染部分cpu消耗异常的问题，这个也会导致卡 @GTC2080

[GTC2080]

还需要看看 webkit 渲染部分cpu消耗异常的问题，这个随之导致卡@GTC2080

确实，现在在排查中

[GTC2080]

继续按新的诊断数据做了一轮取证，#4443 已更新。

这次把 a029618 基线和当前 PR 分支放在同一组合成 workload 下对比，结论是：

1. 原来的历史恢复 payload 问题确实存在。比如 20x5MB-bash-success 的 history+marshal，a029618 大约 79.9ms / 467MB allocation；当前 PR 大约 2.1ms / 75KB allocation。
2. 还有一个独立的 WebKit/renderer 侧热点：Transcript turn grouping 里原来每个 user turn 都会 questions.findIndex(...)，长会话会退化成 O(n²)。在 10000 turns 的合成长会话下，这段计算基线/PR 初版大约 115-116ms，已经足够形成 renderer long task；现在改成单次线性扫描后约 6ms。

所以 #4443 现在不是只做 payload slimming，也包含了这个 Transcript 分组线性化修复。补了 Go 历史 benchmark、前端历史 benchmark 和 transcript-grouping 回归测试，并已跑完整验证：root Go、desktop Go、frontend test:all、frontend build、diff check 都通过。

另外看到 upstream 上有 fix/performance-visibility-resume 分支，它主要是避免 hidden/unfocused 或刚恢复可见时的性能提示误报；这个方向有价值，但它不解决上面这个长 transcript 的 renderer 计算热点。