8 posts tagged with "Electron"

主进程 Node 的 V8 老生代默认约 1.5G，4G 是 Chromium 渲染进程 V8 pointer compression 的硬上限，跟主进程没关系。

1. 主进程：Node.js 同款 V8 默认堆，老生代 64 位约 1400–1536 MB，可调到 ~4 GB 上限
2. 渲染进程：受 pointer compression 限制，V8 堆上限 硬编码 4 GB；off-heap（Buffer / 媒体）走 PartitionAlloc，上限 16 GB
3. 调整方式：主进程走 --js-flags=--max-old-space-size=N；渲染进程走 webPreferences.additionalArguments
4. 不要混：主进程上限给小了，Node 业务（数据库 / 缓存 / 文件处理）会先 OOM；渲染进程上限给大了也不生效，4 GB 是天花板

Electron 目录没有官方推荐，但 三层物理隔离 + main 内按职责拆分 是经得起长期维护的姿势。

1. 三层分离：src/main（Node 全权限）、src/preload（白名单桥）、src/renderer（沙箱 UI），别混
2. 入口最小化：main/index.ts 只做生命周期组装，业务全部下沉到 windows / ipc / services
3. IPC 按域拆：每个域（fs / dialog / store）一个 handler 文件，channel 名集中在 channels.ts 常量
4. Service 层下沉：数据库、文件、网络都封成 service，handler 只做参数转发
5. 窗口工厂：每种窗口一个工厂函数，统一管创建、状态恢复、生命周期
6. 共享类型：main / preload / renderer 之间的 interface 抽到 src/shared，杜绝重复定义

contextBridge 解决的不是"怎么把 API 传给页面"，而是"怎么让页面用 Node 能力但看不到 Node 环境"。

1. 本质：在 isolated world 创建一道有边界的桥，preload 能跑 Node，页面只能摸到白名单 API
2. 机制：preload 跑在 isolated world，主世界（页面）拿不到 preload 的闭包变量，只能拿到白名单出口
3. 能力：exposeInMainWorld 暴露受限 API，序列化约束守住边界（Function、Symbol、Error 不能裸传）
4. 类型系统：preload 内 typeof api + 全局 Window['electronAPI'] 声明，编译期对齐
5. 反模式：暴露整个 ipcRenderer、暴露 process、关掉 contextIsolation

Electron 渲染层的真正主角不是 BrowserWindow，是 webContents。

1. 定位：每个渲染页面背后都有一个 webContents 实例
2. 三种获取方式：BrowserWindow.webContents、webContents.getAllWebContents()、<webview> 标签
3. 核心 API：loadURL、loadFile、导航事件、executeJavaScript、openDevTools
4. 关键推送：webContents.send 是 main 主动通知 renderer 的唯一通道
5. 与 IPC 的关系：send 单向 main → renderer，invoke 反向，组合用才能双向
6. 踩坑：webContents 销毁后再 send 直接抛错
7. 与视图的关系：webContents 是内容，BrowserWindow / webContentsView 是宿主

Electron 的渲染层不是"一个浏览器"，是 Chromium + 多层抽象。

1. Chromium 是底座：每个 Electron 版本绑定一个 Chromium 稳定版
2. webContents 是核心抽象：每个渲染页面背后都有一个 webContents 实例
3. <webview> 标签：在 renderer 里嵌入另一个 webContents
4. webContentsView 是新版抽象：替代已废弃的 BrowserView
5. webPreferences 是渲染配置：preload / contextIsolation / sandbox 等开关
6. 系统 WebView 完全不同：WKWebView / WebView2 是 OS 提供的

Electron 的本质是两个不同类型的进程，IPC 是它们之间唯一合法沟通的桥。

1. 进程模型：一个 main 进程（Node.js 全权限）+ N 个 renderer 进程（Chromium 受限沙箱）
2. IPC 核心：main 用 ipcMain 监听，renderer 用 ipcRenderer 发起，contextBridge 是安全转交
3. 三种调用模式：send/on（单向）、invoke/handle（异步返回值）、MessagePort（双向长连接）
4. 安全铁律：默认开 contextIsolation + nodeIntegration: false，主进程做权限守门人
5. 反模式：在 renderer 里直接 require('fs')、把 token 放 IPC payload、不校验 sender

Electron 日志的三个核心决策点：存哪、怎么切、怎么查。

1. 存哪：主进程写 app.getPath('userData')/logs，渲染进程通过 IPC 转交，不要直接写文件系统
2. 怎么切：按大小滚动 + 按天滚动，绝对不要单文件无上限写入
3. 怎么查：开发环境直接 tail，生产环境用 electron-log 的文件路径 + 崩溃堆栈上报
4. 级别分级：error/warn/info 写文件，debug/trace 仅本地 console
5. 崩溃捕获：JS 异常走 uncaughtException，native 崩溃走 crashReporter，两条路不能混
6. 敏感信息：token / cookie / 密码进日志前必须 redact() 脱敏

Electron 持久化没有"标准答案"，按数据类型选方案，比选库更重要。

1. 写对目录：一律写 app.getPath('userData')，打包后应用目录是只读的。
2. 配置 / 偏好：用 electron-store，一个 JSON 文件搞定，不用自己 fs。
3. 结构化大数据：上 better-sqlite3，同步 API，比 IndexedDB 省心。
4. 敏感信息：token / 密码走 safeStorage，落盘前用系统钥匙串加密。
5. 别踩的坑：renderer 里的 localStorage 会被用户清缓存清掉，不能当数据库。