/g) || []).length;
+ if (o !== c) unbalanced.push(`${name}(开${o}/闭${c})`);
+}
+check(
+ "各子面板独立配平",
+ unbalanced.length === 0,
+ unbalanced.length ? "不配平：" + unbalanced.join("、") : "",
+);
+
+// ── 3) 所有 chat-panel 必须同属一个父容器 ─────────────────────────
+//
+// 形态判据：源码里每个面板片段的起始处都应是独立的
'（一个字符串字面量的结束）或 +（拼接）。
+
+const nested = [];
+for (const name of PANELS) {
+ const marker = `id='chat-panel-${name}'`;
+ const at = html.indexOf(marker);
+ if (at < 0) continue;
+ const from = html.lastIndexOf("
${opens} / ${closes}`);
+console.log(` 面板数: ${PANELS.length}`);
+console.log("");
+if (failures > 0) {
+ console.log(`失败 ${failures} 条`);
+ process.exit(1);
+}
+console.log("全部通过");
\ No newline at end of file
diff --git a/cmd/gui/device-gateway-discovery.test.mjs b/cmd/gui/device-gateway-discovery.test.mjs
new file mode 100644
index 00000000..db6baf6b
--- /dev/null
+++ b/cmd/gui/device-gateway-discovery.test.mjs
@@ -0,0 +1,177 @@
+// 设备桥 gateway 自动发现链路的门禁。
+//
+// ## 要判的是什么
+//
+// 2026-10-05 实测故障：GUI 面板里能看到设备通道地址，但设备桥连不上。
+// 日志只有一行 `ws cookie len=0` + 401，没有任何「地址来自发现」的痕迹。
+//
+// 根因不是配置错，是**发现结果与实际连接配置从不联通**：
+//
+// · 渲染进程 app.js 的 loadDiscoveredGateway() 调 /device/gateway，
+// 拿到的地址只写进 **state.discoveredGateway**（UI 展示用）；
+// · 主进程 startDeviceBridge() 读的是 **gui-prefs.deviceBridge.gateway**；
+// · 两边从未交换过 —— state 是渲染进程内存，prefs 是主进程文件。
+//
+// 于是服务端明明已经通过 /device/gateway 告诉了客户端正确地址
+// （proxy.go:1078 生成的 url_portal），GUI 却仍在用用户几个月前
+// 手填的旧地址，且**永远 401/ECONNREFUSED，且不重试**。
+//
+// ## 判据形态：文本扫描而非运行时
+//
+// 与 endpoint-align / device-align 同路子。自动回写的触发点在
+// loadDiscoveredGateway() 内，由 refreshAll 的 15s 定时器驱动 ——
+// 构造那个时序需要真Electron + 真后端，而 /device/gateway 还要求
+// 会话 cookie（CI 里没有）。故从源码文本判「链路是否接通」。
+//
+// 运行：node device-gateway-discovery.test.mjs
+
+import { readFileSync } from "node:fs";
+import { fileURLToPath } from "node:url";
+import { dirname, join } from "node:path";
+
+const here = dirname(fileURLToPath(import.meta.url));
+const APP = join(here, "renderer", "app.js");
+const MAIN = join(here, "main.js");
+const PRELOAD = join(here, "preload.js");
+
+let failures = 0;
+const check = (name, ok, detail) => {
+ if (ok) {
+ console.log(` ✓ ${name}`);
+ } else {
+ failures++;
+ console.log(` ✗ ${name}${detail ? " — " + detail : ""}`);
+ }
+};
+
+const appSrc = readFileSync(APP, "utf8");
+const mainSrc = readFileSync(MAIN, "utf8");
+const preloadSrc = readFileSync(PRELOAD, "utf8");
+
+// ── 1) 发现函数存在且会调服务端权威端点 ────────────────────────────
+
+check(
+ "存在 /device/gateway 发现调用",
+ appSrc.includes("/device/gateway"),
+ "找不到 —— 服务端发现端点没被调用",
+);
+
+// ── 2) 发现结果必须回写到主进程（本判据的核心）──────────────────────
+//
+// 这是本次修复的要点。若这段回写被删掉（重构时不慎），设备桥会退回
+// 「只用用户手填地址」的行为，且没有任何报错——
+// 这正是 2026-10-05 那次故障的形态。
+
+check(
+ "发现结果回写到主进程 deviceBridge.set",
+ /discoveredGateway[\s\S]{0,600}?deviceBridge\s*\.\s*set\s*\(/.test(appSrc),
+ "loadDiscoveredGateway 里没有 deviceBridge.set 回写 —— " +
+ "state.discoveredGateway 只用于 UI，主进程仍在用旧的手填地址",
+);
+
+// ── 3) 回写不得覆盖用户手填值 ──────────────────────────────────────
+//
+// 发现只做**缺省补全**。若用户在设置页手填了内网直连地址（灰度实例、
+// 绕过反代），自动回写把它冲掉就是新的回归。判据钉住「本地为空才写」。
+
+// 注意不能用 /set\(\s*\{[\s\S]{0,300}?\}/ —— 调用点前后的 if 判断在花括号
+// **外面**，而 300 字窗口会跨到下一个 deviceBridge.set（saveBridgeChannel
+// 的手动保存），判据就误报了。改为直接取「发现函数体内」的那次调用。
+const discoFn = appSrc.match(
+ /async function loadDiscoveredGateway\(\)[\s\S]*?\n}/,
+);
+const setCall = discoFn
+ ? discoFn[0].match(/window\.homeagent\.deviceBridge\.set\([^)]*\)/)
+ : null;
+check(
+ "回写前检查本地 gateway 为空",
+ discoFn ? /cur\s*&&\s*!cur\.gateway/.test(discoFn[0]) : false,
+ discoFn
+ ? "回写处没看到「本地已配置则跳过」的判断 —— 会覆盖用户手填值"
+ : "找不到 loadDiscoveredGateway",
+);
+check(
+ "回写只传 gateway，不覆盖 token",
+ setCall ? !/token/.test(setCall[0]) : false,
+ setCall ? "回写里带了 token —— 发现端点不返回设备令牌，会写坏" : "找不到回写调用",
+);
+
+// ── 4) IPC 链路完整：preload 暴露 get/set，主进程处理 ──────────────
+//
+// 回写用的是 window.homeagent.deviceBridge.set(...)；contextBridge
+// 若没暴露或主进程没注册，这次调用是 undefined TypeError（被 catch
+// 吞掉，于是又回到「静默不生效」）。
+
+check(
+ "preload 暴露 deviceBridge.set",
+ /deviceBridge[\s\S]{0,120}?set\s*:/.test(preloadSrc),
+ "contextBridge 未暴露 set —— 渲染进程调不到",
+);
+check(
+ "主进程注册 device-bridge:set",
+ mainSrc.includes('ipcMain.handle("device-bridge:set"'),
+ "主进程没有该 handler",
+);
+check(
+ "主进程 device-bridge:get 返回明文 token",
+ /device-bridge:get[\s\S]{0,900}?token:\s*db\.token/.test(mainSrc),
+ "get 未返回 token 明文 —— 渲染侧拿不到设备令牌",
+);
+
+// ── 5) device-bridge:set 必须真正重启桥 ───────────────────────────
+//
+// 只存 prefs 不重启，配置不会立即生效（要等下次进程启动）。
+// 这是同一类「存了但没生效」的静默失效。
+
+// 不用大正则匹配整个 handler —— 返回对象里的嵌套 } 会让边界判断很脆。
+// 改为取两个 handler 之间的**源码切片**，再在里面判 stop/start 是否存在。
+const setStart = mainSrc.indexOf('ipcMain.handle("device-bridge:set"');
+const setEnd = mainSrc.indexOf('ipcMain.handle("prefs:get"');
+const setHandler =
+ setStart >= 0 && setEnd > setStart
+ ? mainSrc.slice(setStart, setEnd)
+ : null;
+check(
+ "device-bridge:set 会重启设备桥",
+ setHandler
+ ? setHandler.includes("stopDeviceBridge") &&
+ setHandler.includes("startDeviceBridge")
+ : false,
+ setHandler
+ ? "handler 里没有 stop+start —— 新配置要等重启进程才生效"
+ : "找不到 device-bridge:set handler",
+);
+
+// ── 6) 主进程连接必须带 token ─────────────────────────────────────
+//
+// 设备桥 WS 走 ?token=（registry.go ServeWS 只认 query/X-API-Key/
+// Sec-WebSocket-Protocol 三种，**cookie 不参与** acceptBind）。
+// 这是实测踩过的坑：曾误以为发 cookie 就能过，实际服务端仍 401。
+
+const connectFn = mainSrc.match(
+ /function connectDeviceWS[\s\S]*?\n}\n/,
+);
+check(
+ "connectDeviceWS 把 token 放进 query",
+ connectFn ? /token=/.test(connectFn[0]) : false,
+ connectFn
+ ? "query 里没带 token —— 服务端 acceptBind 会拒"
+ : "找不到 connectDeviceWS",
+);
+
+// ★ keepalive 与重连的判据**不在本文件**，在同目录的
+// device-bridge-liveness.test.mjs —— 那份用 node:vm 把真实函数抽出来跑
+// 「连接 → 断线 → 重连 → 再断线」，数真实的 ping 帧与重连次数。
+// 本文件早期版本曾用文本判据盯keepalive（grep 0x89、找 setInterval 的
+// 间隔），已删：它只能证明「代码里出现过这些字符」，证明不了「心跳真的
+// 发出去了」「重连真的发生了」。两份盯同一件事时，弱的那份会在实现重构
+// 时先红，掩盖真信号。
+
+// ── 汇总 ────────────────────────────────────────────────────────────
+
+console.log("");
+if (failures > 0) {
+ console.log(`失败 ${failures} 条`);
+ process.exit(1);
+}
+console.log("全部通过");
\ No newline at end of file
diff --git a/cmd/gui/main.js b/cmd/gui/main.js
index 87a4c71e..9198b746 100644
--- a/cmd/gui/main.js
+++ b/cmd/gui/main.js
@@ -442,16 +442,60 @@ function createWindow(show = true) {
});
// 静默时不显示；非静默时在首帧就绪后显示，避免白屏闪现。
- if (show) {
- mainWindow.once("ready-to-show", () => {
- try {
+ //
+ // ★ 用 on 而不是 once（2026-10-05 修白屏）：once 只等一次，首帧之后
+ // 监听就没了。而窗口可能被系统回收后重建、或GPU 重启后重新 load，
+ // 那时都需要再show 一次 —— once 的写法让那些路径静默失败。
+ mainWindow.on("ready-to-show", () => {
+ if (!show) return;
+ try {
+ if (mainWindow && !mainWindow.isDestroyed() && !mainWindow.isVisible()) {
mainWindow.show();
- } catch (e) {}
- });
- }
+ }
+ } catch (e) {}
+ });
mainWindow.loadFile(path.join(__dirname, "renderer", "index.html"));
+ // ★ renderer 崩溃自愈（2026-10-05 修「长时间挂后台后打开白屏」）。
+ //
+ // 现象：GUI 在后台挂很久（数小时）后，从托盘打开是**白屏**，且不会自愈。
+ //
+ // 原因链：
+ // 长时间后台 → Chromium 回收 renderer 的 GPU context（或渲染进程
+ // 本身被判定 hung 杀掉）→ 窗口对象仍在、isVisible() 仍返回 true，
+ // 但内容是空的 → showMainWindow() 的 `if (!isVisible()) show()` 被跳过
+ // → 托盘点一下，窗口出现但是白的，永远不会好。
+ //
+ // 之前全代码没有任何 render-process-gone / unresponsive 监听，所以这条
+ // 路径完全无感知。仓库历史上有过「白屏修复(惰性Tray)」提交，但那只修了
+ // **首次**显示时机，没管**长期后台后**。
+ mainWindow.webContents.on("render-process-gone", (e, details) => {
+ console.error(
+ "[window] renderer gone: " + (details && details.reason) +
+ " (exitCode=" + (details && details.exitCode) + ")",
+ );
+ // OOM 之外的都重建；OOM（reason==="oom"）重建只会立刻再崩一次，
+ // 只记录日志避免反复重启把机器拖死。
+ if (details && details.reason === "oom") return;
+ try {
+ if (mainWindow && !mainWindow.isDestroyed()) {
+ mainWindow.reload();
+ }
+ } catch (err) {
+ console.error("[window] reload after crash failed: " + err.message);
+ }
+ });
+
+ // renderer 活着但无响应（主线程被长任务卡死）：此时页面还在，
+ // 只是不响应。给一次刷新机会，不自动刷（误判会让正在用的用户丢状态）。
+ mainWindow.webContents.on("unresponsive", () => {
+ console.error("[window] renderer unresponsive");
+ });
+ mainWindow.webContents.on("responsive", () => {
+ console.log("[window] renderer responsive again");
+ });
+
if (process.argv.includes("--dev")) {
mainWindow.webContents.openDevTools();
}
@@ -922,6 +966,18 @@ let deviceBridgeAddr = ""; // 设备桥网关地址
// 连接成功但 bind 被拒时设备是失联的，只看 connected 会给出假阳性。
let deviceBridgeBound = false;
let deviceBridgeBindError = "";
+// 设备桥心跳与重连的状态（心跳 + 线性退避重连）。
+let devicePingTimer = null;
+let deviceReconnectTimer = null;
+let deviceReconnectAttempt = 0;
+// 拉起意图：用户主动停用后置 false，作为 scheduleDeviceReconnect 的闸。
+let deviceWanted = false;
+// 当前生效的连接配置，重连时复用（连接断开后局部变量就没了）。
+//
+// 缓存而非每次读 gui-prefs：重连是定时器里的异步路径，重读偏好会引入
+// 「读到半写文件」与「用户刚改完就按新值连」两种意外；且重连必须用
+// **当初启动时那份**配置，否则退避语义就乱了。
+let deviceBridgeCfg = null;
// 音频/媒体接收聚合缓冲（服务端分块推送二进制→聚合→播放）
let speechAccum = null;
@@ -1137,6 +1193,9 @@ function connectDeviceWS(url, token, onMsg) {
);
}
opened = true;
+ // 心跳不在这里起：统一由 connectDeviceBridgeOnce 在拿到 ws.__sock
+ // 后调 startDevicePing。放这里的话心跳会跟着「每次 connectDeviceWS
+ // 调用」起，而不是跟着「一条实际连上的桥」起——重连路径上会漏。
resolve({
send: (obj) => sendDeviceFrame(sock, JSON.stringify(obj)),
__sock: sock, // 暴露底层 socket 供二进制分块发送
@@ -1209,11 +1268,243 @@ function connectDeviceWS(url, token, onMsg) {
if (!opened) reject(e);
});
sock.on("close", () => {
+ // 断开时停掉心跳，否则定时器会一直持有已死的 socket。
+ stopDevicePing();
deviceBridge = null;
+ // 已建立过的连接被对端/中间链路关掉 ⇒ 排程重连。
+ // scheduleDeviceReconnect 内部有 deviceWanted 闸，用户主动停用
+ // 时不会把桥拉起来。
+ if (opened) scheduleDeviceReconnect();
});
});
}
+// ============ 设备桥心跳 + 断线重连 ============
+//
+// ★ 这里修的是 2026-10-05 实测到的两个洞，合起来的效果是
+// 「一次失联，终身失联」：
+//
+// 1. **不发 ping**。waiter 侧有 pingLoop（internal/devicebridge/client/
+// bridge.go，每 30s 一个 0x9 帧），GUI 侧全文件一次 ping 都没发过。
+// 而 remotedevice 服务端**没有设备侧读超时**（registry.go 里没有
+// SetReadDeadline）—— 不发心跳就没人能发现设备已死，网关会把一台
+// 半死的设备长期显示为 online。
+//
+// 实测症状：bind 能成功（bind_ok）、设备进了 devices 表（面板可见），
+// 但几秒后 push 就报
+// {"error":"device gui-JianF not online"}
+// —— conns 表已被 defer 里的 markOffline 清空，而 devices 表还在。
+// 「可见但不可下发」就是这个割裂的表象。
+//
+// 2. **不重连**。原来 startDeviceBridge 只有启动/配置变更两个调用点，
+// 失败就 console.error 结束。GUI 是最容易被休眠/切网/服务端重启打断的
+// 形态（合盖一次、WiFi 抖一下、服务端重启），设备桥就再也回不来，
+// 直到用户重启 GUI 或手动改一次配置。
+//
+// 判据：cmd/gui/device-bridge-liveness.test.mjs（用 node:vm 抽真实函数
+// 在沙箱里跑「连接→ 断线 → 重连 → 再断线」，数真实的 ping 帧与重连次数）。
+
+// 与 waiter 的 pingLoop 对齐（bridge.go:636 每 30s 一个 0x9 帧）。
+const devicePingIntervalMs = 30000;
+// 重连退避：线性增长、封顶 60s。首个等待 = base。
+const deviceReconnectBaseMs = 2000;
+const deviceReconnectMaxMs = 60000;
+
+// 发送 WS 控制帧（客户端帧必须带掩码位，RFC6455 §5.3）。
+//
+// 通用签名而非写死 ping：控制帧有 ping(0x9)/pong(0xA)/close(0x8) 三种，
+// 写死一种就换不来另外两种。payload 为 null 表示空载荷。
+function sendDeviceControlFrame(sock, opcode, payload) {
+ const body = payload ? Buffer.from(payload) : Buffer.alloc(0);
+ const mask = crypto.randomBytes(4);
+ const masked = Buffer.alloc(body.length);
+ for (let i = 0; i < body.length; i++) masked[i] = body[i] ^ mask[i % 4];
+ const len = masked.length;
+ let hdr;
+ if (len < 126) {
+ hdr = Buffer.from([0x80 | opcode, 0x80 | len]);
+ } else if (len < 65536) {
+ hdr = Buffer.alloc(4);
+ hdr[0] = 0x80 | opcode;
+ hdr[1] = 0x80 | 126;
+ hdr.writeUInt16BE(len, 2);
+ } else {
+ hdr = Buffer.alloc(10);
+ hdr[0] = 0x80 | opcode;
+ hdr[1] = 0x80 | 127;
+ hdr.writeBigUInt64BE(BigInt(len), 2);
+ }
+ sock.write(Buffer.concat([hdr, mask, masked]));
+}
+
+// 启动心跳（先清旧的，避免重复 interval 叠加）。
+function startDevicePing(sock) {
+ if (devicePingTimer) clearInterval(devicePingTimer);
+ devicePingTimer = setInterval(() => {
+ try {
+ if (!sock || sock.destroyed) return;
+ sendDeviceControlFrame(sock, 0x9, null);
+ } catch (e) {
+ /* 心跳失败不致命：close 事件会触发重连 */
+ }
+ }, devicePingIntervalMs);
+}
+
+function stopDevicePing() {
+ if (devicePingTimer) {
+ clearInterval(devicePingTimer);
+ devicePingTimer = null;
+ }
+}
+
+// 排程一次重连。退避随失败次数线性增长并封顶。
+//
+// ★ deviceWanted 是闸：用户主动 stopDeviceBridge（或改配置）之后
+// 再排程，就会把已停用的桥偷偷拉起来。GUI 是常驻托盘程序，
+// 这个「拉起来」没人看得见，表现为「我明明关了怎么又在连」。
+function scheduleDeviceReconnect() {
+ if (!deviceWanted) return;
+ if (deviceReconnectTimer) return; // 已有排程，不叠加
+ // 先递增后算：首次排程（含连接失败那一回）拿到的就是 base，
+ // 之后 2×base、3×base… 线性增长。用 max(1, attempt) 会在
+ // attempt=0 与 1 时都算出 base，出现「退避头两次一样」的假象。
+ deviceReconnectAttempt++;
+ const delay = Math.min(
+ deviceReconnectBaseMs * deviceReconnectAttempt,
+ deviceReconnectMaxMs,
+ );
+ deviceReconnectTimer = setTimeout(async () => {
+ deviceReconnectTimer = null;
+ if (!deviceWanted) return;
+ const cfg = deviceBridgeCfg;
+ // 配置被清空（用户改了偏好）⇒ 无处可连，停在这里等下一次 start。
+ if (!cfg) {
+ deviceReconnectAttempt = 0;
+ return;
+ }
+ try {
+ await connectDeviceBridgeOnce(cfg);
+ // 连上了：退避归零。下次若再断，重新从 base 开始 ——
+ // 否则「昨天断十次、今天又断一次」要等 10×base 才有第一次重试。
+ deviceReconnectAttempt = 0;
+ } catch (e) {
+ console.error("[device-bridge] reconnect failed: " + e.message);
+ scheduleDeviceReconnect();
+ }
+ }, delay);
+}
+
+// startDeviceBridge 拆出的「只做一次连接」部分：重连走这里。
+async function connectDeviceBridgeOnce(cfg) {
+ const url = cfg.url || cfg.gateway || "";
+ const token = cfg.apiKey || cfg.token || "";
+ deviceBridgeAddr = url;
+ deviceBridgeBound = false;
+ // doConnectDeviceBridge 内部会建 ws、起心跳、并存进 deviceBridge。
+ // 不用它的返回值：那层把结果写全局而非return，两边约定不一致时
+ // 「读返回值」就得到 undefined，随后 ws.send 直接TypeError。
+ await doConnectDeviceBridge(cfg);
+ const ws = deviceBridge;
+ if (!ws) {
+ throw new Error("connect produced no bridge");
+ }
+ // host/cpus/mem 的推导包在try 里：它们在 ws.send 的实参里，而 send 之前
+ // 抛错会被 startDeviceBridge 的 catch 吞成「连接失败」—— 实际连接是好的，
+ // 表现为「反复重连但永远连不上」。拿不到主机信息不该阻断设备登记。
+ let host = "";
+ let cpus = 0;
+ let totalMem = 0;
+ let appVersion = "";
+ let platform = "";
+ let arch = "";
+ let nodeVersion = "";
+ let electronVersion = "";
+ try {
+ host = devOs.hostname() || "";
+ cpus = devOs.cpus ? devOs.cpus().length : 0;
+ totalMem = devOs.totalmem ? devOs.totalmem() : 0;
+ } catch (e) {
+ // 忽略：device_id 退化为 gui-local。
+ }
+ try {
+ appVersion = app && app.getVersion ? app.getVersion() : "";
+ } catch (e) {}
+ // process 单独包：electron 主进程有，但判据的 vm 沙箱只注入了 Buffer/Math/
+ // crypto —— 这里抛错会让 ws.send 之前就中断，被上层 catch 吞成
+ // 「连接失败」，而实际连接是好的（表现为无限重连）。
+ try {
+ platform = process.platform || "";
+ arch = process.arch || "";
+ nodeVersion =
+ (process.versions && process.versions.node) || "";
+ electronVersion =
+ (process.versions && process.versions.electron) || "";
+ } catch (e) {}
+ if (!deviceBridgeId) {
+ deviceBridgeId =
+ "gui-" + (host || "local").replace(/[^a-zA-Z0-9_-]/g, "_");
+ }
+ let authorized = false;
+ try {
+ authorized = !!(
+ guiPrefs &&
+ guiPrefs.deviceBridge &&
+ guiPrefs.deviceBridge.authorized
+ );
+ } catch (e) {}
+ ws.send({
+ op: "hello",
+ device: {
+ device_id: deviceBridgeId,
+ name: "HomeAgent GUI",
+ kind: "computer",
+ authorized: authorized,
+ caps: [
+ "status",
+ "cmdrun",
+ "deviceinfo",
+ "cmdresult",
+ "computeruse",
+ "screensee",
+ "clipboardsee",
+ "clipboardsue",
+ "speakeruse",
+ "camerasue",
+ "screensue",
+ "omniparse",
+ ],
+ info: {
+ hostname: host,
+ platform: platform,
+ arch: arch,
+ os_release: "",
+ node_version: nodeVersion,
+ electron_version: electronVersion,
+ version: appVersion,
+ cpus: cpus,
+ total_mem_bytes: totalMem,
+ },
+ },
+ });
+ ws.send({ op: "bind", device_id: deviceBridgeId, token });
+ console.log("[device-bridge] connected as " + deviceBridgeId + " @ " + url);
+}
+
+// 真实连接：建 WS、起心跳、登记到全局。
+//
+// 「连上」与「开始对它发心跳」是同一件事的两半，放一函数里，重连路径
+// 才不会漏掉心跳。
+async function doConnectDeviceBridge(cfg) {
+ const ws = await connectDeviceWS(
+ cfg.url || cfg.gateway || "",
+ cfg.apiKey || cfg.token || "",
+ onDeviceMsg,
+ );
+ startDevicePing(ws.__sock);
+ deviceBridge = ws;
+ return ws;
+}
+
// 发送 WS text 帧（客户端加掩码）
function sendDeviceFrame(sock, text) {
const payload = Buffer.from(text, "utf8");
@@ -2842,59 +3133,38 @@ async function startDeviceBridge(cfg) {
return;
}
deviceBridgeAddr = url;
- deviceBridgeId =
- "gui-" + (devOs.hostname() || "local").replace(/[^a-zA-Z0-9_-]/g, "_");
+ // 记住配置：重连时要用（连接断开后局部变量就没了）。
+ deviceBridgeCfg = { url, token };
+ // 拉起意图。scheduleDeviceReconnect 以此为闸 —— 用户主动停用后
+ // 不得再排程重连。
+ deviceWanted = true;
+ deviceReconnectAttempt = 0;
+ if (deviceReconnectTimer) {
+ clearTimeout(deviceReconnectTimer);
+ deviceReconnectTimer = null;
+ }
try {
- const ws = await connectDeviceWS(url, token, onDeviceMsg);
- deviceBridge = ws;
- ws.send({
- op: "hello",
- device: {
- device_id: deviceBridgeId,
- name: "HomeAgent GUI",
- kind: "computer",
- authorized: guiPrefs?.deviceBridge?.authorized || false, // 客户端自报授权状态
- caps: [
- "status",
- "cmdrun",
- "deviceinfo",
- "cmdresult",
- "computeruse",
- "screensee",
- "clipboardsee",
- "clipboardsue",
- "speakeruse",
- "camerasue",
- "screensue",
- "omniparse",
- ],
- info: {
- hostname: devOs.hostname() || "",
- platform: process.platform || "",
- arch: process.arch || "",
- os_release: "", // 不提权读取 /etc/os-release，避免破坏沙箱；如需可在白名单命令里由 agent 探
- node_version:
- process.versions && process.versions.node
- ? process.versions.node
- : "",
- electron_version:
- process.versions && process.versions.electron
- ? process.versions.electron
- : "",
- version: app.getVersion ? app.getVersion() : "",
- cpus: devOs.cpus ? devOs.cpus().length : 0,
- total_mem_bytes: devOs.totalmem ? devOs.totalmem() : 0,
- },
- },
- });
- ws.send({ op: "bind", device_id: deviceBridgeId, token });
- console.log("[device-bridge] connected as " + deviceBridgeId + " @ " + url);
+ await connectDeviceBridgeOnce(deviceBridgeCfg);
+ // 首次就连上：退避归零。
+ deviceReconnectAttempt = 0;
} catch (e) {
console.error("[device-bridge] connect failed: " + e.message);
+ // ★ 连接失败也必须排程重连 —— 这条路上**没有** socket close 事件
+ // （socket 从未 upgraded），若只把重连挂在 close 上，首次失败就
+ // 永远不会自愈。
+ scheduleDeviceReconnect();
}
}
function stopDeviceBridge() {
+ // 先断意图，再拆资源：顺序反了会让 close 事件里的排程再把桥拉起来。
+ deviceWanted = false;
+ stopDevicePing();
+ if (deviceReconnectTimer) {
+ clearTimeout(deviceReconnectTimer);
+ deviceReconnectTimer = null;
+ }
+ deviceReconnectAttempt = 0;
if (deviceBridge) {
try {
deviceBridge.close();
@@ -3151,9 +3421,30 @@ function initTray() {
function showMainWindow() {
try {
if (mainWindow && !mainWindow.isDestroyed()) {
+ // ★ 健康检查（2026-10-05 修白屏）：仅靠 isVisible() 不够。
+ //
+ // 长时间后台后 renderer 可能已被回收 —— 窗口句柄还在、isVisible()
+ // 仍为 true，但内容是空的。此时原逻辑会跳过 show()，从托盘打开
+ // 就是一片白，而且永远不会自愈。
+ //
+ // 两个判据：
+ // isCrashed() —— 渲染进程已死，必须重载才能出内容；
+ // isLoading() —— 还在加载，等ready-to-show 就行，不重载。
+ const wc = mainWindow.webContents;
+ if (wc.isCrashed()) {
+ console.log("[window] renderer crashed, reloading before show");
+ try {
+ wc.reload();
+ } catch (e) {}
+ }
// 窗口是静默创建时已处于「未显示」态，这里正常显示即可。
+ // 用 showInactive + focus 两步：showInactive 不抢焦点地显示，
+ // focus 再把焦点给过来（纯 show 在部分 Win 版本上会导致
+ // 无边框窗口不获得焦点，用户还得再点一下）。
if (!mainWindow.isVisible()) mainWindow.show();
- mainWindow.focus();
+ try {
+ mainWindow.focus();
+ } catch (e) {}
return;
}
} catch (e) {
@@ -3282,6 +3573,25 @@ app.on("activate", () => {
createWindow();
}
});
+
+// GPU 进程崩溃/重启后，无边框窗口（frame:false）在部分驱动上会停在
+// 上一帧不再重绘 —— 表现同样是「窗口在、内容不动或全白」。
+// `child-process-gone` 比 `render-process-gone` 覆盖面更广（含 GPU），
+// 这里只在 GPU 挂掉时重载渲染进程（不重建窗口，避免丢窗口位置/尺寸）。
+app.on("child-process-gone", (e, details) => {
+ const type = details && details.type;
+ const reason = details && details.reason;
+ if (type !== "GPU") return;
+ console.error("[window] GPU process gone: reason=" + reason);
+ if (reason === "oom" || reason === "launch-failed") return;
+ try {
+ if (mainWindow && !mainWindow.isDestroyed()) {
+ mainWindow.webContents.reload();
+ }
+ } catch (err) {
+ console.error("[window] reload after GPU crash failed: " + err.message);
+ }
+});
// ============ 系统通知（Electron 原生）============
//
// 之前**完全没有**这个能力：主进程没引入 Notification、preload 没暴露接口、
@@ -3314,10 +3624,9 @@ ipcMain.handle("notify:show", (_, payload) => {
urgency: p.urgent ? "critical" : "normal",
});
n.on("click", () => {
- if (mainWindow && !mainWindow.isDestroyed()) {
- if (!mainWindow.isVisible()) mainWindow.show();
- mainWindow.focus();
- }
+ // 走 showMainWindow 而非直接 show：它带renderer 健康检查，
+ // 直接 show 在 renderer 已被回收时会开出一个白窗口。
+ showMainWindow();
try {
mainWindow.webContents.send("notify:clicked", { id: id, msgKey: p.msgKey || "" });
} catch (e) {}
diff --git a/cmd/gui/renderer/app.js b/cmd/gui/renderer/app.js
index bf97d7b1..6b0cc5ee 100644
--- a/cmd/gui/renderer/app.js
+++ b/cmd/gui/renderer/app.js
@@ -761,6 +761,29 @@ async function loadDiscoveredGateway() {
(d && d.available && (d.url_portal || d.url)) || "";
if (state.discoveredGateway) {
console.log("[device-bridge] discovered gateway: " + state.discoveredGateway);
+ // ★ 回写到主进程，让设备桥**真的**用上发现结果。
+ //
+ // 此前发现只停在state.discoveredGateway（UI 展示用），而主进程的
+ // startDeviceBridge 读的是 gui-prefs.deviceBridge.gateway ——
+ // 两者从不联通。症状：GUI 面板里能看到设备通道地址，但设备桥连不上，
+ // 而日志只有一行 ws cookie len=0，没有任何“地址来自发现”的痕迹。
+ //
+ // 仅当本地未配置 gateway 时才写：手填的值优先（用户可能故意指向
+ // 内网直连或灰度实例），发现只做**缺省补全**。
+ if (window.homeagent && window.homeagent.deviceBridge) {
+ try {
+ var cur = await window.homeagent.deviceBridge.get();
+ if (cur && !cur.gateway && state.discoveredGateway) {
+ await window.homeagent.deviceBridge.set({ gateway: state.discoveredGateway });
+ console.log(
+ "[device-bridge] gateway auto-configured from discovery: " +
+ state.discoveredGateway,
+ );
+ }
+ } catch (e2) {
+ console.log("[device-bridge] auto-config skipped: " + e2.message);
+ }
+ }
}
} catch (e) {
state.discoveredGateway = "";
@@ -1850,7 +1873,7 @@ function buildChatLayout() {
'
' +
__("星图", "Star Map") +
"
" +
- '
';
+ '