遇到多窗口管理的问题，我先确认的是主进程中的窗口引用是否被正确持有，而不是直接去看界面跳转。Electron 的窗口对象一旦失去引用，垃圾回收可能把它回收，窗口会直接消失；窗口已经销毁但引用还留着，后续遍历就会报错。所以先摸清窗口引用的存活情况，再谈父子关系和通信。

先确认现象：窗口引用与存活状态

在 Electron 中管理多窗口时，最直接的做法是创建一个全局数组或 Map 来持有所有 BrowserWindow 实例的引用。主进程中的局部变量一旦被垃圾回收，窗口可能意外关闭，因此通常将窗口列表挂载在 app 或某个单例对象上。每次创建窗口先 push 进入数组，在窗口的 closed 事件中将其从数组移除。判断窗口是否存活时，不能只检查引用是否为 null，要使用 win.isDestroyed() 方法，因为引用可能仍然存在但窗口已销毁。对于常见任务栏切换或激活窗口的操作，可以遍历窗口列表并调用 win.focus() 或 win.show()，前提是 win.isVisible() 和 win.isMinimized() 的状态符合预期。

建立父子窗口关系时要避开的坑

建立父子窗口关系的核心是在构造子窗口时传入 parent 选项。例如 new BrowserWindow({ parent: mainWin, width: 800, height: 600 }) 会创建依附于 mainWin 的子窗口。此时子窗口默认会随父窗口最小化、最大化或关闭而联动，但要注意移动父窗口后子窗口不会自动跟随移动。如果需要强制绑定位置更新，可以监听父窗口的 move 事件，手动调用子窗口的 setPosition 方法。另一种做法是创建主窗口后用 win.setParentWindow(parentWin) 动态设置父子关系，这适合在运行时重组的场景。需要注意的是，如果父窗口被关闭，子窗口不会自动关闭，除非在父窗口的 closed 事件中显式销毁所有子窗口，否则容易造成游离窗口。

这个小节里容易忽略的是 move 事件与 setPosition 的组合。父窗口 move 事件触发频率较高，如果在处理器里直接 setPosition，需要根据父窗口的当前坐标和子窗口的相对偏移重新计算，否则子窗口会一直往右下角跳。我通常先在父窗口 bounds 变化后读取一次子窗口的 bounds，再按差值移动。setParentWindow 适合把一个已经存在的窗口挂到新父窗口上，但调用前要确认原父窗口已经解除关联，否则在某些桌面环境下会出现层级翻转。

通信路径选择：先确认数据流向

父子窗口之间不一定要走主进程转发。先确认消息是单次请求还是持续通知，再选择通道。父窗口向子窗口发送，用 childWindow.webContents.send 即可；子窗口向父窗口发送，创建子窗口时把父窗口的 webContents.id 传进去，再在子窗口里用 ipcRenderer.sendTo 回传。

// 主进程创建子窗口时
const parentId = mainWindow.webContents.id;
const childWin = new BrowserWindow({ parent: mainWindow });

// 向子窗口发送消息，同时带上父窗口 id
childWin.webContents.send('from-parent', { parentId });

// 子窗口渲染进程接收，并向父窗口回消息
const { ipcRenderer } = require('electron');
ipcRenderer.on('from-parent', (event, msg) => {
  console.log('收到父窗口消息', msg);
  ipcRenderer.sendTo(msg.parentId, 'from-child', { ok: true });
});

这个方案里，父子窗口的通信不经过主进程的 ipcMain，少一层中转，调用链路短。需要注意 sendTo 的 targetId 是父窗口的 webContents.id，不是 BrowserWindow 的 id。如果传错，消息会静默丢失，排查时可以先用固定字符串作为 channel，再确认两端监听是否注册成功。更高频的传输可以改用 MessagePort，在创建窗口后等待 did-finish-load 事件再建立通道，适合连续数据流，但代码量会多一些。

生命周期管理的处理顺序

管理多窗口时，必须重视窗口关闭的顺序和资源释放。如果先关闭子窗口再关闭父窗口，通常不会出现异常；但直接关闭父窗口时，子窗口会失去 parent 关系，但不会自动被销毁，需要在父窗口的 close 事件中遍历所有子窗口并调用 destroy()。一个稳健的做法是在子窗口中监听父窗口的 closed 事件，主动触发自身关闭。同时，要避免在窗口的 mousedown 或 click 事件处理中同步创建新窗口，因为事件循环未完成时，窗口引用可能未被正确注册。对于频繁创建和销毁窗口的场景，可以考虑使用 BrowserWindow 的 ready-to-show 事件后再显示，避免白屏闪烁，并且每次创建后主动设置 null 引用，防止内存泄漏。

我会在父窗口的 close 事件里先打断默认关闭，遍历 childWindows 数组，对每个还在存活的子窗口执行 destroy()，然后从数组中移除，再让父窗口继续关闭。处理完这些之后再进入 window-all-closed 回调，否则在 Windows 上容易留下隐藏的 Electron 进程。父窗口的 closed 事件触发后，不能再调用它的方法，所以子窗口里监听父窗口 closed 时，只能做清理，不能尝试访问 parent 窗口属性。

验证与回滚

验证时我会盯三个点：子窗口是否随父窗口最小化或恢复；父子窗口的消息能否往返；直接关闭父窗口后，子窗口是否退出。第一个点需要手动操作窗口的还原按钮，观察子窗口是否恢复；第二个点可以在父窗口渲染进程的控制台打印收到来自子窗口的回包；第三个点通过在主进程里监听每个子窗口的 closed 事件，用计数器确认所有子窗口都走完销毁流程。

如果改动后发现 setParentWindow 导致子窗口位置异常，或者 sendTo 消息丢失，回滚方案是退回构造时直接传 parent 的方式，同时把通信逻辑改回主进程转发。回滚只涉及创建窗口的那一段和渲染进程的监听逻辑，不碰业务数据，但还是建议先在开发环境跑一遍打开、最小化、关闭的完整流程。整体风险边界在窗口生命周期内，只要不把窗口引用误设置为全局缓存里的假引用，就不会影响应用的正常关闭。