必须将 websocket 放入主进程管理，渲染进程仅通过 contextbridge + ipc 通信——因渲染进程生命周期短暂且多窗口易导致连接混乱、无法自动恢复，而主进程可稳定保活、重连与跨窗口同步。
websocket 在 electron 中不能直接在渲染进程里“裸用”就高枕无忧——页面刷新、多窗口、沙箱限制、连接中断后无法自动恢复，这些问题都会让 new websocket(...) 看似简单，实则脆弱。
真正稳定的做法是：主进程管理连接，渲染进程只管展示和触发。这不是过度设计，而是 Electron 架构决定的必然选择。
为什么不能直接在 renderer.js 里 new WebSocket？
常见错误现象：WebSocket is closed before the connection is established 或页面一刷新连接就断，且无法自动恢复；更隐蔽的问题是，多个渲染进程（比如多个窗口）各自建连，导致服务端连接数暴增、认证混乱。
根本原因在于渲染进程生命周期受 HTML 页面控制，而 WebSocket 实例是 JS 对象，随页面销毁而释放。主进程则不同，它独立运行，可长期持有连接、做心跳、重连、消息广播。
使用场景判断：只要你的应用需要「后台保活」「跨窗口同步」「用户切页不掉线」，就必须把 WebSocket 放进主进程。
主进程如何安全暴露 WebSocket 能力给渲染进程？
不能用 nodeIntegration: true + 直接挂全局变量，这是重大安全风险（XSS 可直接调用 require('child_process')）。必须走 contextBridge + ipcRenderer 组合。
在 preload.js 中暴露最小必要接口：
const { contextBridge, ipcRenderer } = require('electron')
<p>contextBridge.exposeInMainWorld('electronAPI', {
connect: (url) => ipcRenderer.invoke('ws:connect', url),
send: (msg) => ipcRenderer.send('ws:send', msg),
onMessage: (callback) => ipcRenderer.on('ws:message', (event, data) => callback(data)),
onClose: (callback) => ipcRenderer.on('ws:close', callback)
})
</p>
关键点：
-
connect用invoke是为了等主进程真正建立连接后再返回，避免渲染进程拿到未就绪的句柄 -
send用send而非invoke，因为发消息不需要等待响应，异步更合理 -
onMessage和onClose必须由渲染进程主动注册，主进程只负责转发事件 - 所有 IPC 频道名（如
ws:connect）必须加前缀，防止与其它模块冲突
主进程中如何实现带重连的 WebSocket 管理？
别写 setInterval(() => ws.ping(), ...) 这种手动心跳——ws 库本身支持 pings 和 pongTimeout，但 Electron 主进程默认没装 ws（浏览器环境用原生 WebSocket，Node 环境才需要第三方库）。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
所以分两种情况：
- 如果你的服务器支持
wss://且不依赖 Node 特有 API（如自定义 TLS 选项），主进程可以直接用浏览器版WebSocket—— Electron 主进程其实也能访问global.WebSocket，但不推荐，因为行为可能因 Chromium 版本漂移 - 更稳妥的是：npm install
ws，并在主进程用它（const { WebSocket } = require('ws')），它专为 Node 设计，重连、超时、错误分类都更可控
一个最小可用的重连逻辑示例（不依赖外部类）：
let ws = null
let reconnectTimer = null
const MAX_RETRY = 5
let retryCount = 0
<p>function connect(url) {
if (ws && ws.readyState === WebSocket.OPEN) return
ws = new WebSocket(url)</p><p>ws.onopen = () => {
retryCount = 0
console.log('WS connected')
}</p><p>ws.onclose = () => {
if (retryCount connect(url), 3000)
}
}</p><p>ws.onerror = (err) => console.error('WS error:', err)
}
</p>
注意：ws.onmessage 里收到数据后，要用 webContents.send() 推给指定渲染进程（不是 ipcMain 广播），否则多窗口会互相干扰。
渲染进程如何正确监听并清理 WebSocket 事件？
最容易被忽略的是内存泄漏：每次页面加载都调用 electronAPI.onMessage(...)，但没在卸载时 removeListener，导致旧回调一直驻留。
正确做法是在组件卸载或 beforeunload 时清理：
const handleMsg = (data) => { /* 更新 UI */ }
electronAPI.onMessage(handleMsg)
<p>// 清理（例如在 Vue 的 beforeUnmount 或 React 的 useEffect cleanup）
window.removeEventListener('beforeunload', cleanup)
function cleanup() {
// electronAPI 提供的 onXXX 方法一般不自带 off，得自己记引用
ipcRenderer.removeAllListeners('ws:message')
ipcRenderer.removeAllListeners('ws:close')
}
</p>
性能影响：如果频繁创建/销毁连接（比如用户快速开关窗口），主进程应维护一个连接池或单例，而不是每次 connect 都新建 WebSocket 实例。
兼容性提示：Electron 20+ 默认启用 contextIsolation: true，任何绕过 contextBridge 直接注入脚本的方式都会失效；同时 remote 模块已废弃，别再查老教程用它。
