[性能/根因] dsh web 启动 2.7s → 17s：0.1.5 的 feat: electron 打包 让 client-modules 全量重组合由 1 次变 8 次（附单文件隔离佐证）

[Start-Gao]

TL;DR

dsh web 启动变慢(本机 2.7s → 17s)的根因已定位到一个提交:

19444907 —「feat: electron 打包」(2026-08-28,+6,906/−92,80 文件)
它把 packages/client/modules/src/index.ts 里 ClientModuleRegistry 的
static inject = ['webServer', 'loader'] 改成了 static inject = ['loader']。

旧写法是一道隐形的延迟闸门:注册表必须等 webServer 就绪才构造,而 Web server 在插件树里较晚就绪,
于是整棵树只在激活波次结束后 compose 一次。改成只依赖 loader 后,注册表随 loader 立即构造,
此后每一波插件激活都触发一次同步全量重组合。

同机、同仪器实测:

系统	客户端字节	compose 次数	compose 总耗时	就绪(中位数)
0.1.2-rc.1 全套 + 09-08 插件集(旧版本)	≈5.3 MB	1	0.43s	2.69s
0.1.5-rc.1 全量(现状)	12.6 MB	8	14.0s	17.3s
0.1.5-rc.1 树 + 仅换回 0.1.2-rc.1 的 client-modules/lib/index.js	12.6 MB	1	1.61s	4.28s

最后一行是单文件隔离实验:客户端图仍是 12.6 MB、其他包一个没动,只换这一个文件,启动即 17.3s → 4.28s。

客户端图确实也变大了(0.1.5 官方客户端包 39 → 45,新增的 ui-sidebar-documentpreview 单包 6.7 MB),
但它只解释约 2.4×;剩余的量级来自 compose 次数 1 → 8。

1. 测量方法(可复现、不改动真实环境)

• 环境:Windows 11,Node v24.14.0,@deepseek-ai/dsh@0.1.5-rc.1(npm latest),
  web profile 9 个 bundle(官方 base/web-app + 7 个第三方)。
• 隔离 DSH_HOME:profiles 用 junction 指向真实 profile,sessions/storages 为空目录,
  全程不在真实 home 上跑第二个实例(避免与正在运行的实例争会话/存储)。
• 真·旧系统重建:用 pnpm 安装 @deepseek-ai/dsh@0.1.2-rc.1 本体到独立目录,以它自己作为
  INSTALL_ANCHOR + 全新 DSH_HOME(启动器、模块回退闭包、client-modules、peer 全是 0.1.2-rc.1,
  无混血),再装上 09-08 那套插件(@liustack/modlens@3.25.4、@liustack/modsearch@5.10.1、
  dsh-better-sidebar@0.18.0、dshmarket@1.41.0、@wingsky-1/dsh-notifier@0.2.1、
  dsh-opencode-session-header@0.1.0)——2.69s 复现了此前的 2.9s 记录。
• compose 计数仪器:用 --import 预加载包住全局 queueMicrotask,统计每次 flush 的耗时
  (≥200ms 记为一次重组合)。旧系统 1 次 / 新系统 8 次,分界清晰。
• 交错 A/B:机器负载会漂移(本机同一配置 1 小时内 12.8s → 17.3s),所以对照实验一律交错执行
  并报中位数,不跨时段比绝对值。

2. 关键数据

2.1 逐版本边界(已发布 npm tarball + 对应源码 ref 双向核对)

版本 / ref	static inject
0.1.2-rc.1(09-03)	['webServer', 'loader']
0.1.3-alpha.2(09-07)	['webServer', 'loader']
提交 19444907(08-28)	['loader']
0.1.5-alpha.1(09-08)/ alpha.2 / rc.1 / rc.2	['loader']

→ 首次进入发布的版本是 0.1.5-alpha.1;0.1.3-alpha.2 及以前都没有。

2.2 该提交的精确改动

-  static inject = ['webServer', 'loader']
+  static inject = ['loader']

   /**
    * Build the service: subscribe, seed, and run the activation flush.
-   * @param ctx - plugin context carrying webServer and loader.
+   * @param ctx - plugin context carrying Loader and an optional Web carrier.
    */
@@
-    ctx.effect(() => ctx.webServer.register({ kind: 'prefix', path: '/plugins', handler: this.serveBundle }), ...)
+    const registerWebCarrier = (webCtx: Context): void => { webCtx.effect(...) }
+    if (ctx.get('webServer') === undefined) ctx.inject(['webServer'], registerWebCarrier)
+    else registerWebCarrier(ctx)

同一提交把双语 README 从"绑定 Web server"改写为"载体无关":
"an available Web carrier serves each bundle over /plugins, and a shell-owned carrier can read
the same graph and bundle paths directly";"A Web carrier renders those rows into its index response;
a shell-owned carrier can render the same rows without a Web server."

2.3 CPU profile(0.1.5-rc.1,17s 采样窗口)

@deepseek-ai/dsh-client-modules 自耗时合计 ≈9.3s,占启动忙时约 65%:
buildCombo 3.15s / newlineCount 2.45s / utf8Write 2.04s / identitySectionMap 1.71s;
官方包自身与第三方插件的 apply 自耗时合计不到 100ms。

2.4 逐项排除

假说	实测	结论
第三方插件太多/质量差	禁用全部第三方客户端行只省 3.0s(12.8→9.8s);第三方客户端字节新旧基本持平	不是主因
机器/杀软	旧系统在同机同负载下 2.69s	不是主因
profile 加载 / 模块回退 / patch 合成	合计 0.25s(16ms + 237ms + 1ms)	不是主因
客户端图变大	新图 12.6MB vs 旧图 ≈5.3MB,×2.4	次要因素(放大器)
compose 次数	1 次 → 8 次	主因

补充:better-sidebar 单独开关的交错 A/B 为 13.9s vs 17.3s(Δ=3.4s),机制是它既让每遍多 879KB,
又多买了一整次重组合(8 次 vs 7 次)。

3. 机制:为什么一个 inject 会放大 8 倍

• compose() 是同步的,现状下单次约 1.6s,阻塞事件循环。
• 注册表在 loader 就绪时即构造;此后每次 internal/plugin(fiber 构造/销毁)都会
  dirty.add(name) + queueMicrotask → flush() → 只要该批有任何变化就 this.compose()(全图全量重算)。
• 同步重算阻塞事件循环 → 剩余插件的激活被推迟到更晚的波次 → 触发更多重组合 → 正反馈。
  这解释了为什么字节只涨 3.7 倍、compose 耗时却涨约 32 倍。
• 旧行为并非刻意设计,但 webServer 这个"必需依赖"事实上充当了"延迟到激活波次结束"的闸门;
  本次为 Electron/壳载体把它变可选时,没有补替代的延迟机制。

4. 建议修法(保留载体无关设计的前提下)

1. 补回延迟/合并:loader.await()(激活静默)后再做首次 compose;或把微任务 flush 去抖为
   "波次结束只 compose 一次";或让 compose 惰性化到首次请求 /plugins。
   这样 README 里 "the shell boots it before any plugin runs" 的诉求也能满足 —— 构造期只注册载体与路由,
   组合推迟到激活静默。
2. 单遍内部降常数(与 [BUG] dsh web 启动到打印 URL 约 18s，其中约 9.3s 来自 client-modules 每次启动重复 8 次全量重建组合包 #6196 / [性能] dsh web 启动 6-7s：client-modules bundle 组装逐字符扫描约 15MB 源码（附 CPU profile 数据） #6369 一致):newlineCount 改 indexOf 扫描;
   identity map 不嵌 sourcesContent(或 .map 完全按需);Buffer.concat 一次;
   去掉"批量 combo + 逐条 combo"双份产物。
3. 按 rev 落盘缓存:抄 Vite optimizeDeps(node_modules/.vite + lockfile/配置失效判定)或
   webpack cache: { type: 'filesystem' },让 12.6MB 的拼装每个版本只做一次。
4. CI 体积闸门:给客户端包设上限(参考 V8 "单 bundle >50–100 kB 就拆"),
   避免单个插件(如 ui-sidebar-documentpreview,6.7 MB 内联 PDF.js)成为启动路径上的固定成本。

方向上与 #6081 提出的"给 Web bundle 的 modules 行补回 webServer 激活边"一致 ——
那个方案解决的是服务访问竞态(webServer without inject),同样也是本次变更的连带影响;
两者的共同点是:modules 行的激活时机需要被显式治理,而不是隐含在包内静态 inject 里。

⚠️ 边界补充（2026-09-12,经本线程讨论后加）：#6081 的激活边只在 Web 组合内成立。桌面宿主没有 webServer 服务（apps/desktop-host/src/index.ts:302-306 只要求 connection/typertGateway/clientModules,并经 clientModules.fetchBundle 供包）,把它上提到包里会让桌面端注册表永不构造 —— 这正是 19444907 里 ctx.get('webServer') === undefined 分支存在的理由。因此正确的根修是让初始扫描等激活稳定（fiber.await() / loader.await(),先例 packages/api/gateway/src/client/index.ts:177）并显式定义未就绪窗口语义,而不是把依赖绑回去。

5. 复现

仪器与脚本(Windows / pwsh + Node):

# 1) 启动计时(隔离 home,预热一次 + N 次取中位数)
node boot-probe.mjs <probeHome> 3 3099
# 2) compose 次数与耗时(包住 queueMicrotask)
$env:DSH_HOME=<probeHome>; $env:PROBE_EXIT_MS=20000
node --import ./probe-microtask.mjs <dsh bin.js> web --port 3140 --no-open
# 3) 交错 A/B(消除机器漂移;overlay 可把某行 disabled 翻回做对照)
node ab-boot.mjs <probeHome> 3120 3
# 4) 分阶段(profile 加载 / 模块回退 / patch 合成)
node split-boot.mjs <probeHome>
# 5) CPU profile 分析
node --import ./prof-exit.mjs --cpu-prof --cpu-prof-dir=<dir> <dsh bin.js> web --port 3099 --no-open
node analyze-cpuprofile.mjs <dir>/boot.cpuprofile

如需脚本原文我可以在回复里贴出(boot-probe.mjs / probe-microtask.mjs / ab-boot.mjs /
split-boot.mjs / analyze-cpuprofile.mjs,均为无依赖的独立脚本)。

6. 方法与局限(如实说明)

• 旧系统是在本机重建的(pnpm 安装 0.1.2-rc.1 本体 + 旧插件),不是历史现场快照;
  但 2.69s 与此前记录的 2.9s 吻合,且 compose 次数 1 次与代码路径一致。
• 隔离 home 无 sessions/storages 数据;真实环境可能比这里的数字更慢。
• better-sidebar 的 A/B 来自真实配置开关;其余对照均用 --patch 覆盖层完成,不改动用户配置。
• 客户端字节数按"每个客户端包 exports['./client'] 指向的产物"统计;图内实际条目以 __DSH_BOOT__
  为准(本次未直接读取该变量)。

相关讨论

• [BUG] dsh web 启动到打印 URL 约 18s，其中约 9.3s 来自 client-modules 每次启动重复 8 次全量重建组合包 #6196 —[BUG] dsh web 启动到打印 URL 约 18s,其中约 9.3s 来自 client-modules 每次启动重复 8 次全量重建组合包(现象一致)
• [性能] dsh web 启动 6-7s：client-modules bundle 组装逐字符扫描约 15MB 源码（附 CPU profile 数据） #6369 —[性能] dsh web 启动 6-7s:client-modules bundle 组装逐字符扫描约 15MB 源码(热点一致)
• [Performance][Windows][0.1.2-rc.1] Published npm packages in flat ZIP: cold Web startup dominated by synchronous file reads #5807 —[Performance][Windows][0.1.2-rc.1] cold Web startup dominated by synchronous file reads
• Web bundle should declare modules -> webServer activation dependency #6081 — Web bundle should declare modules -> webServer activation dependency(激活时机,方向一致)
• dsh web hangs at startup — pegs one CPU core, never binds 127.0.0.1:3080 (Windows 11) #4944 — dsh web hangs at startup — pegs one CPU core, never binds 127.0.0.1:3080(启动期长时间无输出)

---

English summary

Root cause of the slow dsh web startup (2.7s → 17s) is one commit:
19444907 "feat: electron 打包" (2026-08-28), which changed ClientModuleRegistry's
static inject from ['webServer', 'loader'] to ['loader'] in packages/client/modules/src/index.ts
(so a shell-owned carrier can run without a Web server — a legitimate goal).

That removal also deleted an accidental gate: the registry used to be constructed only after
webServer existed, i.e. after the Loader's activation waves had finished, so the whole graph was
composed once. Now it is constructed as soon as loader exists, and every subsequent plugin
activation triggers a synchronous full recomposition.

Measured on the same machine with the same instruments:

System	client bytes	compose runs	compose time	time to URL
0.1.2-rc.1 (full, 09-08 plugin set)	~5.3 MB	1	0.43s	2.69s
0.1.5-rc.1 (current)	12.6 MB	8	14.0s	17.3s
0.1.5-rc.1 tree with only client-modules/lib/index.js reverted	12.6 MB	1	1.61s	4.28s

The 3.7× larger client graph (0.1.5 added 6 client packages; ui-sidebar-documentpreview alone is
6.7 MB of inlined PDF.js) explains only ~2.4×; the rest is the 1 → 8 recomposition count.
Because compose() is synchronous and takes ~1.6s, it blocks the event loop, pushing later activations
into further waves — a positive feedback loop.

Suggested fix: keep the carrier-agnostic design but restore deferral/coalescing (first compose after
loader.await(), or debounce the microtask flush to one compose per activation wave, or compose lazily
on the first /plugins request). Consistent with #6196 and #6369. Boundary note: #6081's activation edge is Web-composition-only and is not the root fix — see above.

---

[argszero]

根因定位我独立复核过，三条都成立。但修法这一层有一个会踩坑的地方，#6081 的提议如果被当成性能修复采纳，会把"慢"换成"桌面端不启动"。下面是我这边读码得到的边界与两条独立杠杆。

独立复核

• 引入提交与版本边界：逐 tag git show 验证 static inject —— dsh-v0.1.2-rc.1 / dsh-v0.1.3-alpha.2 = ['webServer','loader']；dsh-v0.1.5-alpha.1 / dsh-v0.1.5-rc.2 = ['loader']。与你的表完全一致。19444907（07akioni，2026-08-28）的 diff 也正是那三处（static inject + registerWebCarrier + ctx.get('webServer') === undefined 分支）。
• 8 次 compose 的代码路径成立：构造期 :529 把全部 entry 名种入 dirty 集 → :530 compose → :532 flush() 再 compose；此后 internal/plugin 每来一个 fiber（:514-524）就 queueMicrotask 一次，flush 若判定 changed 就全量 compose()（:958-972）。
• 我不主张作者有意用 inject 做闸门 —— 该提交同批把双语 README 从"绑定 Web server"改写为"an available Web carrier / 载体无关"，意图就是脱钩。闸门效应是这次脱钩的副产品，所以修法不能是"把依赖绑回去"。

★ 为什么"加回 inject"不能当根修

桌面端根本没有 webServer 服务。apps/desktop-host/src/index.ts:306 的启动前置只要求 connection / typertGateway / clientModules；:200 由 shell 自己的 carrier 调 ctx.clientModules.fetchBundle(request) 供 /plugins/。而 webServer 是 packages/bundle/web-app/cordis.patch.yml:177 那套 Web 组合才有的行。

所以：

• Web bundle should declare modules -> webServer activation dependency #6081 在组合侧加 inject: [webServer] 是合理的（Web 组合里确实该有这条激活边，服务访问竞态那条也真实）—— 但它只对 Web 面成立；
• 若把它当作本问题的修复，ClientModuleRegistry 在桌面端将永不构造（webServer 永远不会出现）⇒ 比 17s 更糟：客户端包一个都拿不到。19444907 的 ctx.get('webServer') === undefined 分支正是为此存在。
• 我不建议用 $inject$ 顺序或"先 etcd 后 x"式的时序 hack 绕过 —— 那是把当前脆弱性固化。

★ 正确的根修：让初始扫描等激活稳定，而不是绑回某个兄弟服务

仓库里已有现成信号和现成先例：

• 信号：fiber.await()（vendor/cordis/src/fiber.ts:704-710）等的是 该 fiber 自身的 inertia（即"当前生命周期工作"），不引入对任何兄弟服务的依赖 ⇒ 桌面端同样满足。
• 先例：packages/api/gateway/src/client/index.ts:177 —— void loader.await().then(start, () => {})，生产代码已这么用（测试里的用法就更多了）。

把初始扫描从"构造即跑"改成"loader 激活稳定后再跑"，启动期 compose 从 8 次降到 1–2 次（稳态那 1 次仍属必要，它是幂等收敛）。两点必须一并处理：

1. 未就绪窗口要显式回答：fetchBundle:574 → bundleResource:982 在 this.responses 里查不到就落 404。窗口内必须回"未就绪"（或让 carrier 等待）而不是 404，否则会换成一个更难的首屏 404。
2. 锚点必须是 loader fiber，不是 ctx —— 用 ctx.fiber.await() 会形成依赖环。packages/client/web/src/boot-client.ts:54 是"client 侧显式 await 后再 boot"的现成形状，可作语义参照。

★ 第二个独立杠杆：compose() 的派生结果跨调用完全没有缓存

这一条与 compose 次数正交，可以单独落地。compose() 每跑一次都要重建全部派生数据：

• comboSource（:254-263）对每个包重做 record.bundle.toString('utf8') + 两趟正则替换 —— 每次都是 Buffer→JS 字符串的全量解码，即使 record.bundle 与 rev 一模一样；
• identitySectionMap（:323-333）重建 mappings（Array.from({length: newlineCount(source)}) 拼 ;），且 sourcesContent: [source] 让同一份源码在 map JSON 里再存一份；
• :680-690 还为每个包额外再构建一次单包 combo（buildCombo([record], rev)），叠加在同一批字节上；
• newlineCount（:296-300）用 for (const char of value) 逐字符遍历 —— 你引的 CPU profile 热点就是它。

按 record.rev 键控缓存这三项（源码字符串、map、单包 artifact），在 8 次 compose × 65 包 × ~10–15MB 的量级上正好覆盖你说的 4.3s → 14s 那一段。注意：这不能替代上面那条 —— 只做缓存仍会做 8 次表排序/分组合图与 8 份 batchResponses，只是把最贵的那部分降下来；两条一起做才回到"接近旧行为但保留载体无关"。

边界

以上全部读自 c291e7961a；我没有复现你的计时（本机无 dsh 安装、也不是 Windows / Node 24.14 —— 我这边只有 Node 26.5.0）。我复测的是代码路径与版本边界：逐 tag 验证了 static inject，确认桌面端无 webServer，确认构造期 compose 两次与 flush 全量重组的路径；8 次这个计数是你的仪器结果，我未独立复测（你的 queueMicrotask 包装法可复现，我没条件跑）。另外 :530 那次 compose 我描述为"非空表下必被 :532 的 flush 覆盖"而非死代码 —— changed === false（一个 client 包都没有）时它是唯一给 composed 赋值的路径，删之前要保证该分支仍有初值。

---

TL;DR (EN) — The root-cause chain is verified independently (commit 19444907; tag boundary 0.1.5-alpha.1; the double-compose plus per-flush full recompose path). But restoring inject: ['webServer'] is not a usable fix: the desktop host has no webServer service (apps/desktop-host/src/index.ts:306 requires only connection/typertGateway/clientModules, served via the shell carrier), so that edge would leave the registry permanently unconstructed there — worse than slow. #6081's composition-side edge is right for the Web composition only. The real fix is to let the initial scan wait for activation to settle (fiber.await(), precedent packages/api/gateway/src/client/index.ts:177) rather than re-couple to a sibling service — anchor on the loader fiber, not ctx, and answer explicitly from the not-ready window instead of 404-ing the bundles. Second, orthogonal lever: nothing in compose() is memoized across calls (comboSource re-decodes every bundle to a string, identitySectionMap rebuilds mappings and duplicates the source in sourcesContent, plus a per-record extra combo) — keying those by record.rev is cheap and covers exactly the 4.3s→14s gap, but it does not replace the first fix.

[Start-Gao]

@argszero 感谢这段复核 —— 桌面宿主那条我独立验证确认了，而且它纠正了我此前的一处表述。

1) 桌面端没有 webServer：确认，并补一个易误读点
在 c291e7961a 上复核：apps/desktop-host/src/index.ts:302-306 只要求 connection / typertGateway / clientModules，缺任一即抛 "composition did not provide connection, typertGateway, and clientModules"；:200 由 shell carrier 直接 ctx.clientModules.fetchBundle(request) 供 /plugins/。
易误读处：该文件 L27 只从 @deepseek-ai/dsh-host-webserver 导入 renderIndexInjections 及其 IndexInjection 类型（L191 还 emit webserver/index-inject），所以对 webServer 做文本 grep 会命中，但那是类型/工具而非服务 —— 我第一遍也差点看错。

2) 接受对 #6081 那条交叉引用的边界修正
我写的"该激活边很可能同时修掉启动耗时"只在 Web 组合内成立（那里确实有 webServer，恢复晚构造即恢复 1–2 次 compose），不能上提到包里，否则就是你说的桌面端永不构造。已在该帖补一句边界说明。

3) 你的修法 (1)：两条实测支撑，以及对你两个前提的回应

• 目标量级正确：旧行为（延迟构造）实测 1 次 compose / 0.29–0.43s，全旧系统 time-to-URL 2.69s；在当前 0.1.5 树上只把 client-modules/lib/index.js 换回旧版，同样是 1 次 / 1.61s / 4.28s。
• (a) 未就绪窗口不是假设，今天就已经存在：一次 profile 采样里 dsh web: 横幅在 ~12.4s 打出，而重组合持续到 ~14.4s —— URL 已交给浏览器、图上还在重建，窗口约 2s 宽。所以这条语义现在就该定义，而不是修完才需要。
• (b) 锚点同意必须锚在 loader fiber 上（ctx.fiber.await() 会成环）。我核对了你引的 packages/client/web/src/boot-client.ts:54，那里确实是 await loader.await() 紧接着 assertEntriesActive(ctx)，即调用方显式等激活后再 boot。这给出一个值得在设计里写明的区分：延迟放在注册表内部时必须自带未就绪语义（因为 /plugins 可能在窗口内被请求）；放在调用方（如 boot-client）则窗口移出注册表，但 Web 组合里 index 注入与路由注册仍可能落在窗口内 —— 两条路都绕不开 (a)。

4) "不要用时序 hack 绕过"：完全同意，并想补一个可 review 的边界
loader.await() / fiber.await() 是静默（quiescence）语义 —— 等的是这棵树自己收敛，不是"猜一个时序"。反过来，任何固定延迟、固定 microtask 次数、或依赖兄弟服务出现顺序的写法，都会把你说的脆弱性固化。建议在设计里显式写一行"不得引入时序常量"，让它在 review 时可以被直接判定。

5) 杠杆 (2)：同意正交，而且是乘数不是替代
我用复刻 compose() 的微基准（真实 86 条记录 / 12.6MB，热 JIT）量过：单遍现状约 0.76s，仅把 newlineCount 换成 indexOf 扫描约 1.7×。但主导项是遍数（1→8），所以按 record.rev 键控缓存是"把每遍变便宜"，与"减少遍数"相乘 —— 与你的结论一致。（微基准是算法复刻 + 热态，绝对值偏乐观，只用来看相对量级。）

6) 你对构造期那次 compose 的提醒同样成立
内置产物里 flush() 在无变更时是 if (!changed) return; 提前返回，所以零 client 包的组合下，构造期那次 compose() 确实是 composed 的唯一赋值路径，修的时候必须保留初值。

7) 你没条件复测计时，我这边可以补齐条件
计数就是"包住全局 queueMicrotask，统计每次 flush 耗时（≥200ms 记为一次重组合）"，再配交错 A/B（同机负载会漂移：同一配置 1 小时内 12.8s → 17.3s，跨时段比绝对值会得出错误结论）。需要的话我把 probe-microtask.mjs / ab-boot.mjs / boot-probe.mjs 原文贴出来；除 Windows 的 taskkill 外无外部依赖（macOS 换成对进程组发信号即可），Node 26 应该能直接跑。

[PerryLink]

核实结论：属实，机制逐行成立。

• 提交 1944490（feat: electron 打包，80 files +6906/−92）三处 diff 与你引用逐字吻合：static inject 由 ['webServer', 'loader'] 改为 ['loader']、引入 registerWebCarrier、ctx.get('webServer') === undefined 分支。
• 版本边界表完全正确：0.1.2-rc.1 / 0.1.3-alpha.2 仍是 ['webServer','loader']，0.1.5-alpha.1 起变 ['loader']（各 tag 的 git grep 证实）。
• 重组合机制成立：packages/client/modules/src/index.ts —— internal/plugin 事件 → microtask flush（:514-524）；flush 有变化即同步全量 compose()（:946-972，:958 早退、:961 全量）；compose 每包单包 combo（:680-690）→ 每包双份产物；newlineCount 逐字符扫描（:296-300）；identitySectionMap 重复内嵌源码（:323-333）。
• argszero 的桌面端边界（desktop-host/src/index.ts:301-306 不要求 webServer、shell carrier 直调 fetchBundle）与 loader.await() 先例（gateway client:175-177、boot-client.ts:54-55）也成立。

边界：「8 次」与 2.7s→17s 是实测，我未独立复测；源码只能证实「每次 flush 全量重组合、无去抖无合并」，不能反推精确次数。修法方向同意：初始扫描等 loader 激活稳定（锚 loader fiber）+ compose 派生产物按 rev 缓存（正交杠杆）。

[Start-Gao]

@PerryLink 感谢逐行核对 —— 你引的每一处行号我都对着 c291e7961a 复核过，全部命中：:296-300 逐字符 newlineCount、:323-333 identitySectionMap（含 :330 的 sourcesContent: [source]）、:514-524 internal/plugin 监听、:680-690 每包单包 combo（:681 的 buildCombo([record], record.entry.rev)）、:958 的 if (!changed) return 早退与 :961 的全量 compose()。
你转述的 argszero 那两条边界我也复核过：apps/desktop-host/src/index.ts:301-306 确实不含 webServer（只要求 connection/clientModules/typertGateway），先例 packages/api/gateway/src/client/index.ts:175-177 与 packages/client/web/src/boot-client.ts:54-55 逐字吻合。

你那句"源码只能证实『每次 flush 全量重组合、无去抖无合并』，不能反推精确次数"——完全同意，而且可以再收紧一层：这个次数本身不是常量，它是组合的函数。
同机、同一份代码，随启用组合变化：

组合	重组合次数
9 bundle（better-sidebar 开）	8
9 bundle（better-sidebar 关）	7
第三方行全禁	6

所以"从源码推次数"不只是不可靠，而是连一个确定的数都不存在 —— 它由激活波次决定。这反过来支持同一结论：修法必须是结构性的（把初始扫描推迟到激活稳定，或把 flush 去抖合并），而不是去调一个常数。（次数与耗时都由包住全局 queueMicrotask 的探针计数得出，≥200ms 记一次重组合。）

目前这条线只剩一个开放的设计问题：推迟之后"未就绪窗口"的语义。fetchBundle → bundleResource 在 this.responses 查不到就返回 404，窗口内应回"未就绪"还是让 carrier 等待，需要和载体侧一起定。

[cningan]

补一份直接计数的独立佐证——不是从 flush 耗时反推，而是用 ESM 加载钩子把 compose() 本体包起来，每次调用记一行：序号 / 当时表里多少行 / 本次毫秒。

环境：Windows 11，Node v24.15.0，@deepseek-ai/dsh@0.1.5-rc.1，真实 web profile（组合树 168 条目、61 个启用的客户端 bundle、合计 11.52MB；其中 ui-sidebar-documentpreview 6.57MB）。隔离实例 dsh --profile web --port 0 --no-open。

[compose] #1  rows=0    0ms      ← 构造期建空表
[compose] #2  rows=45   513ms
[compose] #3  rows=46   516ms
[compose] #4  rows=55   578ms
[compose] #5  rows=56   574ms
[compose] #6  rows=57   591ms
[compose] #7  rows=59   593ms
[compose] #8  rows=60   604ms
[compose] #9  rows=61   626ms
[compose] #10 rows=62   606ms

→ 本机是 10 次（比你那台多两次），符合你「次数是组合的函数、不是常量」的判断：这台机器启用组合更大。10 次合计 ≈5.2s，占该配置启动 8.0s 的约 65%。

两点补充：

1. 单轮耗时几乎不随行数增长（45 行 513ms vs 62 行 606ms），说明单轮成本主要是按字节算的（11.5MB × 每字节约 3.8 次扫描），而不是按条目数；放大系数 ≈ compose 次数 × 客户端总字节，两个乘数都值得下手。
2. 单轮本身也还有一大截可摘：同样这 10 轮，只把 newlineCount 的逐字符实现换成 indexOf（内存内改写，其他一律不动），单轮降到 267–345ms，启动 8.02s / 8.31s → 5.67s / 5.67s。即在你定位的 ×8/×10 放大之外，单轮成本还有约 2.5s，代价是一行代码（原帖 [性能] dsh web 启动 6-7s：client-modules bundle 组装逐字符扫描约 15MB 源码（附 CPU profile 数据） #6369 有该热点的 profile 归因；我这边补的是端到端数字）。