Electron中Redis发布订阅同步状态必须由主进程连接Redis并收发消息，渲染进程仅通过IPC接收更新；因渲染进程沙箱限制无法直连Redis，且官方要求系统级I/O须在主进程执行。
Electron 本身不内置 Redis 客户端，也不能直接在渲染进程里连 Redis（Node.js API 被默认禁用，且存在安全与跨域限制），所以“在 Electron 中用 Redis 发布订阅同步状态”这件事，必须拆成两个明确角色：主进程负责连接 Redis 并收发消息，渲染进程只负责 UI 更新和触发本地事件——中间靠 ipcMain / ipcRenderer 桥接。
为什么不能在渲染进程直连 Redis
渲染进程默认运行在 Chromium 的沙箱环境里，require('redis') 会报错，net、tls 等底层模块不可用；即使通过预加载脚本放开部分 Node.js API，也违背最小权限原则，容易引发远程代码执行风险。官方明确建议：所有系统级 I/O（包括 Redis 连接）必须放在主进程。
- 预加载脚本从 Electron 20 开始默认沙盒化，
require只能加载events、timers、url等极少数模块 - Redis 客户端依赖
net和stream，这两个模块在沙盒中被完全屏蔽 - 即便绕过沙盒（如设
nodeIntegration: true），也会让整个渲染进程暴露在高危攻击面下
主进程中用 redis-cli 或 ioredis 实现 Pub/Sub
推荐使用 ioredis（比原生 redis 模块更健壮，自动重连、支持集群、Promise 友好）。主进程启动时建立一个全局订阅客户端，监听指定频道，收到消息后通过 webContents.send 推给对应窗口。
- 安装依赖：
pnpm add ioredis -S（注意是-S，不是-D） - 在
main.js里初始化订阅者，不要用new Redis()，改用new Redis.Cluster()或带重连配置的单例 - 频道名建议带命名空间，比如
app:sync:ui-state，避免和其他服务冲突 - 收到消息后，检查
webContents是否还存活再send，否则会报Cannot read property 'send' of null
const Redis = require('ioredis');
const redisSub = new Redis({ host: 'localhost', port: 6379, retry_strategy: () => 1000 });
redisSub.subscribe('app:sync:ui-state', (err, count) => {
if (err) console.error('Redis subscribe error:', err);
});
redisSub.on('message', (channel, message) => {
try {
const data = JSON.parse(message);
mainWindow?.webContents?.send('redis:state-update', data);
} catch (e) {
console.warn('Invalid Redis message:', message);
}
});
渲染进程如何安全接收并响应 Redis 消息
渲染进程不能主动连 Redis，但可以监听主进程转发来的 IPC 消息。关键点在于：别在 useEffect 或 mounted 里重复注册监听器，也别忘了卸载时取消订阅。
- 用
ipcRenderer.on监听redis:state-update，不要用once（除非你只要一次） - 如果用 React，确保监听器注册在组件挂载时，清理函数里调用
ipcRenderer.removeAllListeners - 消息体必须是可序列化的 plain object，
Date、Map、Buffer等类型会在 IPC 传输中丢失或报错 - 避免在监听回调里直接操作 DOM，优先更新 React/Vue 状态，让框架驱动 UI
import { ipcRenderer } from 'electron';
ipcRenderer.on('redis:state-update', (event, payload) => {
console.log('Received state sync:', payload);
// 更新你的 local state，例如 useState 或 pinia store
});
状态同步的边界在哪？别指望 Redis 替你做 UI 渲染
Redis Pub/Sub 只解决「消息通路」问题，它不保证顺序、不提供 ACK、不缓存历史（除非你额外加 Stream）、也不管谁在线谁掉线。Electron 应用的状态同步粒度，得由你自己定义清楚：
- 是同步用户偏好设置？用
app:config:update频道，payload 带key和value - 是同步文件列表变更？别传整个数组，只传
{ type: 'added', file: 'xxx.pdf' }这种增量结构 - 是多窗口共享编辑状态？需要自己维护窗口 ID 映射表，主进程按
windowId分发，而不是广播给所有窗口 - 别把 Redis 当数据库用——它没有事务、没有查询能力，状态快照仍得落盘（如
app.getPath('userData')）
最容易被忽略的是连接生命周期管理：主进程重启、Redis 临时断连、网络抖动，都会导致消息丢失。真要强一致性，得在业务层加补偿逻辑，比如定时拉取全量状态 + Redis 做增量通知，两者结合。
