如何正确修复Electron应用中的Object Destroyed错误？

首先明确：用try-catch包裹win.webContents.send确实不是最优解，本质是在错误发生后被动捕获，而非从根源避免问题。

错误原因 #

当Electron窗口（BrowserWindow实例）已经被销毁后，再调用其webContents.send方法，就会触发"object destroyed"错误——此时win或win.webContents对应的原生对象已被释放，无法执行通信操作。

正确修复方法 #

1. 提前检查窗口/ webContents的存活状态

调用send前，先判断窗口是否还存在且未被销毁：

ipcMain.on('aMessage', async e => {
    // 处理消息逻辑
    const res = await someAsyncOperation();

    // 先校验窗口状态
    if (win && !win.isDestroyed() && win.webContents) {
        win.webContents.send('position', res.data);
    }
});

win.isDestroyed()是Electron原生方法，能准确判断窗口是否已销毁，比try-catch更高效，逻辑也更严谨。

2. 监听窗口销毁事件，清理IPC监听

如果IPC监听器长期存在，窗口销毁后应主动移除对应监听，避免后续触发无效操作：

// 窗口创建时绑定销毁监听
win.on('closed', () => {
    ipcMain.removeListener('aMessage', handleAMessage);
    // 释放窗口引用，辅助垃圾回收
    win = null;
});

// 单独定义IPC处理函数，方便后续移除
async function handleAMessage(e) {
    // 处理消息逻辑
    const res = await someAsyncOperation();
    if (win && !win.isDestroyed() && win.webContents) {
        win.webContents.send('position', res.data);
    }
}

ipcMain.on('aMessage', handleAMessage);

这种方式从根源上避免了窗口销毁后还触发IPC处理逻辑的可能。

3. 使用IPC事件的sender对象（场景允许时）

如果回复是针对发起IPC的窗口，直接用回调里的e.sender代替全局win引用——e.sender是当前发起请求的webContents实例，即使回复时窗口已销毁，调用send只会静默失败，不会抛出错误：

ipcMain.on('aMessage', async e => {
    // 处理消息逻辑
    const res = await someAsyncOperation();
    // 用e.sender替代全局win.webContents
    e.sender.send('position', res.data);
});

注：如果异步操作耗时较长，期间用户关闭窗口，e.sender.send不会报错，但也不会产生效果，这属于合理行为。

为什么不推荐try-catch？ #

• 属于事后补救，无法避免无效代码执行；
• 频繁使用会带来微小性能损耗；
• 无法从根源解决窗口销毁后逻辑冗余的问题。

内容的提问来源于stack exchange，提问作者Eugene1111