上周接了个需求，要在鸿蒙PC版的Electron应用里Zuo分屏编辑——左边是项目列表，右边双击打开详情页，Zui多同时开四个窗口。听起来不复杂，对吧？我在Windows上半小时就写了个demo，信心满满地丢到鸿蒙PC上跑，结果一晚上过去，窗口间传个数据跟打地鼠似的，这个收了那个丢，关了窗口内存还不释放。

说实话，这事真挺折磨人的。下面记录一下我踩过的坑，以及Zui后跑通的方案。

Electron的BrowserWindow有个id属性，官方文档说它是递增的整数。我在Windows上惯用的套路是：

const win = new BrowserWindow;windowMap.set; // key就是1,,,...

这样后续按ID发消息、关窗口清理，douhen省事。可同样的代码放到鸿蒙PC上，win.id直接给我来了个，中间空了一大截。我一开始以为是代码哪里多实例化了加了日志一kan，每new BrowserWindow一次id确实在涨，但就是不连续。

后来翻Chromium源码才明白，鸿蒙PC上的窗口管理走了UIExtensionAbility的框架，Electron底层每创建一个窗口，实际上要和系统的WindowManager注册一次中间有些内部窗口也占ID。这就导致BrowserWindow的id不是严格递增的。

我推荐的Zuo法是放弃依赖win.id，自己维护一套映射：

// main/utils/safe-ipc.jsfunction sendToWindow { if ) return; const wc = win.webContents; // 鸿蒙PC后台窗口IPC可Neng丢消息，先"戳"一下 if ) { wc.executeJavaScript.catch => {}); // 空脚本，只为唤醒渲染循环 } // 给一点缓冲时间 setImmediate => { if ) { wc.send; } });}function broadcast { for ) { sendToWindow; }}module.exports = { sendToWindow, broadcast }; 第二个坑：后台窗口收不到IPC消息

我在Windows和macOS上dou没见过这情况。排查了两个小时加了一堆console.log，发现消息确实从主进程发出去了但后台窗口的webContents好像进入了某种"冻结"状态。

** workaround 是在发送前强制唤醒目标窗口的渲染进程：**

Zui终我搞了一个基于主进程转发的"伪BroadcastChannel"：

// preload.jsconst { contextBridge, ipcRenderer } = require;const listeners = new Set;ipcRenderer.on => { listeners.forEach; } catch { console.error; } });});contextBridge.exposeInMainWorld => ipcRenderer.invoke, onBroadcast: => { listeners.add; return => listeners.delete; }});

// main/index.jsipcMain.handle => { // 转发给所有存活窗口 for ) { sendToWindow; }}); 顺便说说为什么百度不收录我的文章呢？这个问题困扰了我hen久。

** 有人说是内容质量的问题，也有人说是关键词密度的问题。**

** 我觉得dou有点道理，但又好像不是那么回事。**

** 说实话，我也不太清楚，或许是我运气不好吧。**

这个行为非常反直觉。我Zui后的解决方案是双重保险：既监听closed，又监听close，还在webContents的destroyed事件里Zuo兜底清理。

function trackWindowLifecycle { let cleaned = false; const doCleanup = => { if return; cleaned = true; windowRegistry.delete; broadcastToAll; // 强制释放webContents引用，帮助GC if ) { win.webContents.removeAllListeners; } win.removeAllListeners; }; win.on; win.on; win.webContents.on;} 把碎片拼起来

** 把上面这些碎片拼起来就是我目前在鸿蒙PC上稳定运行的多窗口管理模块。**

**核心文件就三个：window-manager.js 负责创建和注册窗口 ， safe-ipc.js 处理可靠广播 ， preload.js 暴露给渲染进程用的API。 **

本文遵循 MIT 协议转载授权。

不过要提醒的是这套方案目前只在Electron + 鸿蒙PC .2上验证过。Electron $之后Chromium内核升级了不少 ， IPC的实现可Neng也有变化，建议升级前先在测试环境跑一遍全套 窗口压力测试 。

// main/window-manager.jsconst windowRegistry = new Map; function createEditorWindow {// ...trackWindowLifecycle;}module.exports = { createEditorWindow };

三重监听 + $秒强制清理，这套组合拳上去之后 内存终于稳住了。关 窗口 后内存Neng回落到基线附近，再也没有泄露。