~/requests 界面停留时间久了，数据量大的时候会卡死

[luodaoyi]

问题背景
~/requests 界面停留时间久了，数据量大的时候会卡死

需求说明

需要限制数量，长时间运行必然卡死，整个浏览器都会无响应，
应该要限制最大数量，实现滚动窗口刷新

现在只有供应商和状态，需要加一个过滤器，实现不同API令牌的过滤，另外最好状态可以多选，比如同时显示传输中和等待中的

[luodaoyi]

• P0：useStreamingRequests() 不是单例，页面常驻组件会重复订阅 + 重复 setState
  • 每个调用者都会各自订阅 proxy_request_update 并 setActiveRequests(new Map(prev))：web/src/hooks/use-streaming.ts:90、:63
  • 侧边栏就至少 2 处常驻在用：web/src/components/layout/app-sidebar/requests-nav-item.tsx:10、web/src/components/layout/app-
• P1：/requests 无限列表会“越跑越长”（DOM/缓存膨胀），你不滚也会变慢
  • RequestsPage 直接渲染 allRequests.map(...)：web/src/pages/requests/index.tsx:315
  • WS 更新对 infinite query：当没命中已有项，会把“新请求”塞进第一页，但没有做 pageSize 上限裁剪：web/src/hooks/queries/use-
    requests.ts:241
  • 同时 knownRequestIds 是无上限增长的 Set：web/src/hooks/queries/use-requests.ts:87、:277
  • 这会导致打开时间越久，内存/GC/渲染成本越高。
• P2：即使 WS 已批处理，/requests 仍然是“整表重渲染”模型
  • 父组件任何 state 更新（包括 nowMs 每秒 tick：web/src/pages/requests/index.tsx:123）都会让父组件重跑 allRequests.map，行组件
    不是 memo 化模型，成本会随行数线性上涨。

复查：

1. LogRow 无 React.memo → nowMs 每秒 tick 仍会让所有行重渲染（存在）

• onClick={() => navigate(...)} 每次 render 都创建新函数：web/src/pages/requests/index.tsx:328
  结论：你说的“每秒父组件重渲染导致所有行无条件重渲染”是对的；但它并不等于“方案失效”——它至少把原来“每行 100ms”降到了“全页
  1000ms”，只是还没把 O(N) 每秒重绘降到只更新必要行。

2. 后端 attempt 广播“按事件即时推送”，确实没节流（存在）；但“每 token 触发一次 metrics”需要看 adapter（你描述的那种极端不一定成
   立）

• 其中 EventMetrics 会触发推送：internal/executor/executor.go:342-369
• 但多数流式 adapter 的 SendMetrics/SendResponseInfo(完整 body)是在流结束时发一次（例如 Codex 流式在 sendFinalStreamEvents 里提取
  并 SendMetrics：internal/adapter/provider/codex/adapter.go:465-490；Custom/Antigravity 也类似在 sendFinalEvents 里：internal/
  adapter/provider/custom/adapter.go:343-372、internal/adapter/provider/antigravity/adapter.go:772-805）。
  结论：“attempt 更新事件无节流”成立；但“每 token 一次 metrics→海量 attempt WS”在当前代码里不一定（更常见是：开始/首 token/结束时
  几次事件，各自都会触发一次 attempt 广播）。

3. 单请求生命周期多次 proxy_request_update 推送（存在，7-10 次在重试/取消场景很常见）
   至少这些地方都会推 BroadcastProxyRequest：

• ingress 创建后推一次：internal/executor/middleware_ingress.go:112-118
• route match 置为 IN_PROGRESS 推一次：internal/executor/middleware_route_match.go:65-71
• dispatch 选中 route/provider、每次 attempt 开始/结束、成功/失败/取消等多处推：internal/executor/middleware_dispatch.go（例
  如 :39-41、:112-116、:229-231、:304-307、:321-324、:368-371、:392-394）
• egress 兜底（请求还在 IN_PROGRESS 时）也会再推：internal/executor/middleware_egress.go:19-38
  结论：你说的“并发 100 → 700~1000 msg/s”在“重试多/状态变更多/attempt 事件也在推”的组合下是完全可能的。

更致命的隐患：

• WS proxy_request_update 推的是完整 ProxyRequest：internal/handler/websocket.go:83-88
• ProxyRequest 里包含 RequestInfo.Body / ResponseInfo.Body 字符串：internal/domain/model.go:319-322
• 前端每帧都主线程 JSON.parse：web/src/lib/transport/http-transport.ts:819-827
  如果流式请求的 ResponseInfo.Body 很大（或你把 SSE 全量累计进 body），哪怕事件频率不夸张，也会直接把 Chrome 主线程和 GC 打爆。

实测发现body超级大

[SurviveM]

#246