[性能] 多插件环境下刷新页面全量重下全部 bundle（no-cache），主线程拥塞致插件延迟 10-20s；建议按 rev immutable 缓存

[Wildareasilence]

一句话

刷新页面后所有插件 bundle 无缓存全量重下、重新执行，多插件环境（50 个 bundle / 4.9MB）下浏览器主线程拥塞，尾部落地的插件（如 whale-girl 宠物）延迟 10-20s 才显示。

复现

• 环境：DSH 0.1.0-rc.6 / web profile / Windows 11，安装 @linxin666/dsh-web-ui-all（14 个插件）+ whale-girl
• 步骤：刷新页面（Ctrl+Shift+R），观察右下角宠物出现时间
• 实际：10-20s（禁用全家桶后立刻出现）
• 预期：刷新后秒级加载

根因

dsh-client-modules.serveBundle 对所有插件 bundle 返回 cache-control: no-cache，而 bundle URL 本身带内容哈希 rev（/plugins/<id>/client.js?rev=<hash>）——rev 不变内容必不变，完全具备 immutable 长缓存的语义条件。当前每次刷新都全量重下 50 个 bundle（实测 4.9MB）并重新解析执行，主线程被占满；请求数量多、初始化重的插件（whale-girl 16 个素材请求 + 15 次逐像素扫描）排最后，被拖到 10-20s。

建议

• bundle 响应按 rev 提供 public, max-age=31536000, immutable（rev 变则 URL 变，天然失效）；开发期热重载场景可仅对无 rev / 调试请求保留 no-cache
• 参考：whale-girl 素材路由同样 no-cache，本机改为 immutable 后问题立刻消失（相关 issue：[性能] 多插件环境（web-ui 全家桶）下刷新页面宠物 10-20s 才加载；素材路由缓存头 + idle 优先加载可解决 vlln/whale-girl#6）

验收条件

• 多插件环境下刷新页面，插件（含第三方宠物等）秒级出现
• 开发期改源码后 HMR/刷新仍能看到新内容（rev 变化机制不受影响）

用户侧临时缓解（已本机验证）

• 第三方插件素材路由加 immutable 缓存头 + 首屏优先加载（详见 [性能] 多插件环境（web-ui 全家桶）下刷新页面宠物 10-20s 才加载；素材路由缓存头 + idle 优先加载可解决 vlln/whale-girl#6）；平台层 bundle 缓存仍需官方修复。

[zoahdev]

This is the classic "bundle URL is stable but content isn't content-hashed" failure.

Likely root cause

The plugin client bundles are served from stable URLs (e.g. /plugin/<id>/client.js) without a per-revision cache key, so a page refresh revalidates (or refetches) every bundle even when unchanged. With many plugins that's a serial wall of fetches + parse on the main thread → 10-20s jank.

Fix direction (in order of leverage)

1. Content-hash + immutable: serve bundles as /plugin/<id>/<rev>/client.js with Cache-Control: immutable; the rev is already tracked per plugin, so the URL changes only on real updates.
2. Split download from parse: fetch bundles in parallel and evaluate off the critical path (or requestIdleCallback / worker) so the main thread isn't blocked by N parses.
3. A manifest endpoint: one /plugins/manifest listing {id, rev, urls} so the client fetches one small JSON and diffs instead of N requests.

Happy to help measure this against a multi-plugin profile and prepare a cherry-pick-ready patch if maintainers want a concrete baseline (fetches, bytes, parse time) before/after.

[Wildareasilence]

补充：本机已实施平台层最小补丁，附官方源码验证（供上游参考）

已在本地 dsh-client-modules.serveBundle 实施该建议并验证，补充几个实测发现：

1. rev 机制确认（已对照官方 npm 包验证）

• rev = shortHash = sha1 内容哈希取前 12 位（官方源码 L86-88：createHash("sha1").update(input).digest("hex").slice(0, 12)）
• 为排除本机补丁干扰，已从 npm registry 下载官方 @deepseek-ai/dsh-client-modules@0.1.0-rc.6 tarball 逐字节对比：rev 语义区域（L86-347）与本机零差异，本机补丁仅 252 字节且只在 serveBundle 响应头区域
• 运行时实测：boot entry rev 0629eccd2119 == 磁盘 bundle 文件 sha1[:12] ✅
• 关键语义：rev 在服务器激活时计算一次（initialBundleRevision = shortHash(readFileSync(clientPath))）；运行中仅 HMR watch 的 rebuilt() 钩子重算——而 web profile 组合树里 cordis-plugin-hmr 被 dsh-web-app 禁用（hmr: disabled: true），运行中改 bundle 文件 rev 不会更新

2. 对开发流程的影响（实施 immutable 后）

• 运行中改插件文件 + 普通刷新 → 浏览器命中缓存旧版
• 硬刷新（Ctrl+Shift+R）或重启 dsh web（rev 重算 → URL 变）→ 正常看到新内容
• 补丁已保留豁免：不带 ?rev= 的裸请求仍返回 no-cache

3. 收益预期修正

实测全量下载 50 个 bundle / 4.9MB 仅 0.32s——immutable 缓存能省的网络开销有限；5-6s 主体是浏览器端 JS 解析执行（4.9MB 解析 + 全家桶 14 插件初始化）。缓存额外收益是激活 V8 字节码缓存（二次加载解析加速）。治本仍需：减少默认加载插件数量 / 平台懒加载与代码分割。

4. 本机参考实现（serveBundle 内 1 处）

const hasRev = new URL(req.url ?? "/", "http://x").searchParams.has("rev");
res.writeHead(200, {
  "content-type": isSourceMap ? "application/json; charset=utf-8" : "text/javascript; charset=utf-8",
  "cache-control": hasRev ? "public, max-age=31536000, immutable" : "no-cache"
});

验证：重开标签页不再全量重下；动态插件（cordis_run 等）走独立通道不受影响。

[Wildareasilence]

@zoahdev 感谢分析，但关于 rev 语义需要澄清——官方源码与实测都表明当前 dsh 已经是"内容哈希 + URL 携带 rev"，缺的只是缓存头：

dsh源码证据

1. rev = 内容哈希：dsh-client-modules 官方源码 L87-88 shortHash(input) = createHash("sha1").update(input).digest("hex").slice(0, 12)，注释即 "sha1 content hash shortened to 12 hex chars (bundle rev / graph rev)"
2. URL 已带 rev：官方 graphRow（L91-98）生成 /plugins/<id>/client.js?rev=<rev>，boot entries 均为此形态
3. 内容变化 → URL 变化：rev 在服务器激活时基于当前文件计算（initialBundleRevision = shortHash(readFileSync(clientPath))），更新文件后重启 dsh → rev 重算 → URL 变化
4. 实测佐证：本机 boot entry rev 0629eccd2119 == 文件 sha1[:12]
   所以"fix direction 1"（content-hash + immutable）当前形态已就位，唯一缺的是 serveBundle 缓存头（no-cache → public, max-age=31536000, immutable），参考 diff 见上一条补充评论。

两点补充

• 语义前提：rev 只在激活时重算（cordis-plugin-hmr 在 web profile 默认禁用，运行中 rebuilt() 无人调用）——"URL 只在真实更新时变化"成立，前提是插件更新伴随 dsh 重启；运行中直接改 bundle 文件不会更新 rev（开发者需硬刷新或重启）
• 同意你的方向 2：下载仅 0.32s（4.9MB），主线程 JS 解析执行才是 5-6s 主体；主线程外解析/懒加载是更值得做的优化，与缓存建议互补

如果你愿意做多插件 profile 的前后基线测量（fetches / bytes / parse time），数据会很有说服力。