[GT-610]

概述

本 PR 只做请求路径与控制面的性能优化：减少每次请求里的重复计算、重复联网和重复轮询，不改变任何对外行为契约——线上字节、缓存前缀、重试预算、协议回退顺序、用量语义全部保持原样。

10 个提交，18 个文件，+1025 / -103，基于 main 的 ac06537（v0.15.1 之后）。每处改动都有对应测试，且每个新增用例都先对着回退后的实现跑过，确认会红。

优化清单

Batch 1：纯本地计算，不改变 I/O 行为

1. 凭据解析与正文装配并行 (c92ee87)
   streamAttempt() 原本严格串行：先等完 resolveApiKey()（账号池选择、凭据读取，必要时还有探测），再读图并装配正文。两者其实互不依赖——正文从不携带密钥，健康账号池的解析也只读内存——等待时间一直是相加而非重叠的。现在把与密钥无关的通道判断先算成 provisionalProtocol，buildBody() 与 resolveApiKey() 并发；凭据返回后目标一致即复用已装配的正文，不一致才重建一次。

2. 选择器在目录已在内存时不再等一次联网刷新 (2413e6b)
   listModels() 去掉无条件 await gatewayFacts.refresh()：本进程已加载过该网关目录时直接返回内存里的行，刷新放到后台。新判据 GatewayFacts.loaded() 刻意与 snapshot() 区分——后者读磁盘，而磁盘缓存没有年龄校验，拿它当首屏会画出不知道多久以前的目录。进程首次加载仍照旧等联网。

3. 超时定级复用已序列化的正文 (ed3785c)
   gradeHeaderTimeout() 判断「这次超时是不是刚刚那份载荷」时原本调 fingerprintValue(body)，内部又 JSON.stringify 一遍——而正文在发出去之前已经序列化过了。带图历史可达数 MB，连续超时恰恰是最常重复的路径。现在直接对实发字符串 sha256Hex()，只哈希字节。这同时更准确：实发字符串就是网关看到的字节，重新 stringify 会在 surrogate 清洗真的删掉过字符时描述到不同的字节，把一次连续超时拆成两条 streak。

4. 工具 schema 归一化按对象身份记忆化 (cd8c240)
   每个通道在每次尝试时都重建工具列表，而账号轮换、协议回退、降档重试都会让同一批 schema 再走一遍。现在按 parameters 的对象身份用 WeakMap 记住根节点结果；工具对象来自宿主、整个回合稳定，所以 identity 就是精确的键。只有根节点记忆化，嵌套 $ref／组合子仍走原递归路径。顺带纠正一处与实现对不上的注释（type: 'object' 快路径一直返回调用方自己的对象）。

Batch 2：控制面去重（不碰请求主路径）

5. 账户事实在用量卡片与套餐过滤之间共享 (f28fcfb)
   设置卡片的账户区与选择器的套餐过滤读的是同一批端点、同一个账号：whoami 一次，再并行 credits + subscriptions 一次，而卡片还在定时刷新，选择器于是反复为它早就拿到过的行再付一次往返。现在把成功的账户端点响应按「网关 + 密钥 + 完整 URL」记进短命表（ACCOUNT_FACTS_TTL_MS，30 秒）共用。刻意只缓存成功响应：失败必须重试，否则刚恢复的端点会继续报告昨天的故障。/alpha/usage/summary 明确不参与共享（share=false）——那是用户正盯着、旁边写着读取时间的数字。

6. 没人点的刷新在短窗口内合并 (9aa836a)
   refresh() 接受 auto 标记：只有自动路径（首屏、后台 tick）会在 USAGE_AUTO_REFRESH_COALESCE_MS（5 秒）内复用刚刚 settled 的结果；按钮、保存配置、更换凭据等显式调用一律不传 auto，永远去读。窗口刻意很小——它只折叠一次重复，不是用来展示旧数据，fetchedAt 因此仍如实反映读取时刻。

7. 隐藏的页面不再轮询 (7634528)
   后台标签页的 React 树仍然挂着，而自动刷新循环继续每两分钟为一个没人看的页面付四次上游调用。现在 tick 先问可见性：文档隐藏时跳过读取但照旧重排定时器（循环不能断），重新可见立即补读一次——那是唯一「已知屏幕上数据已过期」的时刻。首屏仍无条件读取。可见性做成可注入接缝（AutoRefreshVisibility），默认读 document.visibilityState；非浏览器环境视为始终可见；最后一个挂载停止时解绑监听。

8. 首屏自动路径与显式路径分开 (17b2b5d, d206c13)
   把 injected 面拆成 refreshUsageAuto()（内部 refresh({ auto: true })）与 refreshUsage()：AccountsCard 的首屏 effect 走前者，刷新按钮走后者。两者在类型上分开，让「这个能合并、那个不能」在调用点就看得出来。

明确没有改动的部分

• 历史 reasoning 的重放策略（缓存前缀稳定性，见 经常报错：Command Code stream error: The reasoning_content in the thinking mode must be passed back to the API. #34）
• accept-encoding: identity（见 无法使用了 #59）
• offloadSeenImagesForCache 的默认值
• temperature: options.temperature ?? 0.3
• CLI 传输里静态的 config 块
• 各类重试预算（TRANSIENT_MAX_RETRIES / DEFAULT_TRANSPORT_MAX_RETRIES / MAX_ACCOUNT_ROTATIONS / 头部超时连击上限）
• 各类缓存 TTL 的既有语义
• 用量汇总在多个界面之间的共享

另有两批优化没有进这个 PR：stream_options: { include_usage: true }（需要先做一次线上探针确认网关行为）与历史 reasoning 策略（默认关闭、风险更高），留作后续单独讨论。

验证情况

• npm run typecheck：退出码 0
• npm ci 干净安装后 npm test：1120 / 1120 通过
• npm run build：两段 Build complete，重建后 git status 对 lib/ 无差异（提交的 bundle 与源码一致）
• 分支基于 ac06537，10 个提交，无 merge commit

关于 tests/web-search.test.ts：我第一次在本机跑全量时这里失败了 16 条，原因是本地 node_modules 与 lockfile 漂移（实装 @deepseek-ai/dsh-web 0.2.1-alpha.3，lockfile 钉 0.2.1-rc.2），按 lockfile 重装（npm ci）后即全绿。与代码无关，但如果有人本地复现同样的红，先查这个。

建议的人工验证

正确性靠"行为不变"来保证，以下几项值得人工过一遍（按优先级）：

1. 图片工具路径的延迟——第 1、3 条的收益在这里最明显
2. 三种传输（CLI / OpenAI / Anthropic）各跑一次多轮工具调用——确认请求体与此前一致
3. Anthropic 的 prompt cache 命中率——确认 cache_control 前缀字节没变
4. 大历史下的超时恢复——第 3 条的直接受益场景
5. 多账号轮换与协议回退——确认第 5 条的共享缓存没有串号
6. 模型选择器：热态秒开 / 冷启动无幽灵目录
7. 账户卡片：首屏自动读取 vs 点刷新按钮手动读取
8. 多账号下的用量面板——确认没有重复请求
9. 后台标签页——确认不再轮询，切回来立刻有一次新鲜读取
10. 首屏用量卡片——确认与之前观感一致

回滚

按批次与优化点分别提交，可单独 revert 任意一条；Batch 2 的几条彼此独立。

[Mars-Sea]

已由 #101 承接：该 PR 合并了本 PR 的全部提交（作者署名保留），并额外修复了审查中发现的几个真实问题——图片预算门抢在凭据之前抛错（会让宿主对发不出去的请求先做不可逆的图片卸载）、loaded() 把磁盘行当成联网热数据、刷新失败后空目录冒充热数据、可见性监听随卸载顺序泄漏，以及补上账户卡片首屏 auto 接线的真实渲染测试。差异只有两个提交（4a0921a 代码与测试、31d95de 文档），本 PR 可以关闭；如需保留这里的讨论，可在 #101 继续。