桌面端启动期间没有任何窗口（已配置账号的用户），反复点击图标无反应并堆积进程

[hZsFN]

环境

• DSH Desktop 0.2.1-rc.2（nightly 通道，win32-x64）
• Windows 10/11
• 账号已配置（已登录 / 已存 API Key），插件约 225 个

现象

双击图标后，桌面和任务栏上长时间不出现任何窗口，没有 splash、没有进度、没有任何提示。用户无法判断是在启动还是卡死了，于是反复点图标——任务管理器里能看到一长串进程，"点很多次才打得开 + 后台起了一堆进程"。

根因：已配置用户启动时，主窗口要等页面加载完才 show，而欢迎窗口不会出现

resources/app.asar → lib/main.js（0.2.1-rc.2）：

// L11935  主窗口创建时 show 默认为 false
function createWindow(preload, show = false, primary = false) { ... }

// L12888-12889  主窗口就是用默认值创建的 → 创建即隐藏
const createMainWindow = () => {
  const window = createWindow(appPreload, false, true);

// L12937-12944  只有进工作区、并且页面导航完成后才显示
const enterWorkspace = async ({ activate = true } = {}) => {
  const window = mainWindow ?? createMainWindow();
  await navigateMain(applicationUrl);          // ← 等 web 服务起来
  if (isQuitting() || recovery.active || window.isDestroyed()) return;
  if (activate) window.show();
  enteredWorkspace = true;

// L8569-8571  只有「既没登录、也没有 API Key」才会走欢迎窗口
function needsWelcome(authentication) {
  return !authentication.loggedIn && !authentication.hasApiKey;
}

// L13015-13029  启动入口
const openInitialWindow = async () => {
  if (quitting || recovery.active) return;
  const state = await readWelcomeState();
  if (isQuitting() || backend.state.phase !== "ready") return;
  ...
  if (!enteredWorkspace && needsWelcome({ loggedIn: state.loggedIn, hasApiKey: state.hasApiKey })) {
    raiseAfterUpdate = false;
    await showWelcome();      // 首次使用者：有欢迎窗口可看
  } else await enterWorkspace();   // 已配置用户：直达主窗口，但这期间什么都看不到
};

// L13031-13053  启动期间点图标走这里
focusPrimaryWindow = () => {
  ...
  if (window === mainWindow && !enteredWorkspace) return;   // ← 静默返回
  if (window.isMinimized()) window.restore();
  window.show();
  window.focus();
};

也就是说：

• 首次使用的用户（无登录、无 key）启动时会看到欢迎窗口，体验是正常的；
• 已经配置过的用户 needsWelcome 返回 false，直接走 enterWorkspace()，而它第一件事是 await navigateMain()，在页面加载完成之前主窗口一直是隐藏的；
• 这段时间里点图标会触发 second-instance → focusPrimaryWindow，但 enteredWorkspace 还是 false，于是直接 return：不显示、不聚焦、不提示。

实测时间线

用自制的 cordis 探针（监听 internal/plugin 事件 + 20ms 采样事件循环 lag）测到的：

时点	事件
+0	主进程启动
+3.57 s	探针插件才被 apply（之前是 Electron 初始化 + 解析配置）
+3.91 s	一个 3.58 s 的一次性长任务结束，220 个 fiber 在此刻同时出现（解析配置 + 建树 + 206 个插件同步 apply，期间一次 tick 都跑不了）
+6.69 s	全部 225 个插件 ACTIVE
≈ +14.9 s	配置重写完成（RECOVER）
之后	web 就绪 → navigateMain 返回 → 才 window.show()

而且插件全部就绪之后，主线程还有 4 次明显长卡（此时没有任何插件在 apply，loading=[none]）：

+19.2 s → 卡 2.09 s
+24.5 s → 卡 4.93 s
+32.4 s → 卡 5.30 s
+41.1 s → 卡 6.77 s  ← peak

累计 19 秒，正好落在用户反复点图标的那段时间里——即使窗口提前显示了，这段时间界面也会是卡死的。

建议

1. 主窗口创建后就 show()，内容区先渲染一个 skeleton / "正在启动…" 的本地占位页，等 navigateMain 完成再切真实页面。宁可先给一个空白窗口，也比"什么都没有"强得多。
2. focusPrimaryWindow 在 !enteredWorkspace 时不要再静默 return：至少 window.show() 出来（哪怕还是占位页），或者闪烁任务栏，让用户知道程序活着。
3. 启动超过 2~3 秒时在窗口内显示当前阶段（"加载插件 137/225" 之类）。
4. 顺便：那 4 次 2~6.8 秒的 loading=[none] 长卡如果也能 profile 掉就更好了，它们在启动完成后直接表现为界面卡顿。

备注

以上是本机实测 + 直接读 app.asar 内 lib/main.js 得出的，行号对应 0.2.1-rc.2。如果这是已知问题或者不该在这里提，抱歉打扰。

[hZsFN]

更新：补一份「启动之后还慢在哪」的实测（同一台机器、225 个插件）

接着上面的现象往下追了一步：窗口能出来了，但从窗口出现到真正能打字，中间还有肉眼可见的空档。这份是这段时间攒下来的数据，供参考。

环境：Desktop 0.2.1-rc.2 / win32-x64 / Windows，约 225 个插件，同一账号配置；探针挂主线程计时（process.hrtime 采样 + 分阶段归因），单次启动 164 次 apply、约 40 s 窗口。

1. 找到一处具体来源：usage 轮询每次同步重读整份配置

组成	耗时
readFileUtf8	858 ms
structuredClone	848 ms
existsSync（逐 namespace）	733 ms
其余	~660 ms

第三方插件 dsh-usage 的定时刷新在主线程同步调用 dsh-config-editor 的 configuration()，后者每次都是 readFileUtf8 + structuredClone + 全 namespace existsSync，实测单次 3.1 s。本地实验性地给 readNamespace 加了一层 WeakMap(ctx) → Map(namespace) 缓存（TTL 3 s，可开关），只此一处：

• overview 端点 p50 1.15–1.82 s → 115 ms（命中 0.5–0.8 ms，miss 143–152 ms）
• 对应的主线程停顿消失（该段不再出现 >1 s 的 STALL）

这条不只对 dsh-usage 有效——任何在轮询/定时器里读配置的插件都走同一条路径。

2. fibers 全 active 之前的 5.4 s，98% 是 Node 模块解析

首次全 active 出现在 +6.7 s；之前的停顿集中在三段：workspace 2.38 s、schedule 2.78 s、session-projection-cache 0.71 s。把这 5.39 s 按 syscall 拆开：

分类	耗时	占比
internalModuleStat	2156 ms	40.0%
realpathSync	1493 ms	27.7%
lstat / statSync	1337 ms	24.8%
readFileUtf8	191 ms	3.5%
structuredClone 等	217 ms	4.0%

涉及约 660 个包的入口解析。把安全软件暂停后只快约 40%，所以不是 fs 过滤的问题，是解析次数本身。

3. 单插件成本抽样（首次 apply）

核心合计 15.0 s；第三方合计 ≈2.9 s，头部三个分别是 833 ms / 710 ms / 378 ms。按这个分布，即使把第三方插件全关也只省约 1 s——瓶颈不在"插件多"。

4. 仍然没解释的部分

• 全 active 之后还有 6 次 4–11 s 的停顿（peak stall 7120 / 5823 / 11212 / 8461 / 5674 / 5814 ms），此时探针的阶段标记一律是 [none]，无法归因；
• +19 s 附近一次稳定的 ~1.6 s 停顿，未定位；
• 「点图标 → 真的能打字」这条端到端指标，目前还没有可信的 A/B 计时。

5. 方法学上的诚实说明

上面第 1 条的收益来自只有 1 次热启动的样本；active 之前变快大概率是热启动（文件缓存 + V8 code cache），不能算补丁功劳。用户侧的主观感受仍是"提升不大"——所以我倾向于先把十次以上冷启动的基线打实，再谈优化。

如果需要，我可以把探针整理成一个可复现的最小脚本贴上来（主线程占用计时 + 阶段归因 + syscall 分类，只依赖 process.hrtime 与公开的 hook 点，不侵入引擎）。