Electron集成Sqlite数据库的最佳实践咨询

1. 是否可以/建议将数据库逻辑放在渲染进程（React）侧实现？ #

技术上能跑通，但强烈不建议，核心问题两点：

• 安全风险完全不可控：BetterSqlite3是原生Node模块，要在渲染进程运行必须关掉Electron默认的全套安全配置：开nodeIntegration、关contextIsolation、关渲染进程沙箱。改完之后渲染进程里所有脚本——不管是你自己写的业务代码、第三方依赖，还是被XSS注入的恶意脚本——都能直接拿到完整系统权限，任意删改本地文件、执行系统命令，等于把大门完全敞开。你用的ERB脚手架默认是开全安全配置的，硬改配置适配渲染层跑数据库，完全违背脚手架的安全设计初衷。
• 稳定性差：BetterSqlite3是同步驱动，如果你开多个应用窗口，每个窗口的渲染进程各自连数据库，非常容易触发SQLite写锁冲突，轻则抛错，重则损坏数据库文件。而且同步的长查询直接跑在渲染进程的话，会占住UI线程，直接导致页面掉帧、操作无响应。

2. 不放在渲染层的话，是否需要通过IPC完成主进程和渲染层的数据收发？ #

对，这是Electron官方推荐的标准实现方式，ERB本身已经预置了IPC的封装，不用从零搭。
落地的时候别踩两个坑：

• 别直接把ipcRenderer整个通过preload暴露给渲染进程，用contextBridge只暴露封装好的业务方法，暴露的面越小越安全。
• 别写那种接收任意SQL语句直接执行的通用IPC通道，要按业务场景拆成细粒度的接口，比如todo:getList、note:add这种，所有传入的参数都做类型、格式校验，从根源上堵SQL注入的可能。
  最简实现参考：

// 主进程代码：初始化数据库、注册IPC处理逻辑
const Database = require('better-sqlite3');
const { ipcMain } = require('electron');
// 数据库实例仅在主进程持有
const db = new Database('app.db');

ipcMain.handle('todo:getList', (_, status) => {
  // 先校验参数合法性，再用预编译SQL绑定参数执行
  if (!['all', 'done', 'pending'].includes(status)) throw new Error('非法参数');
  return db.prepare('SELECT * FROM todos WHERE status = ?').all(status);
});

// preload脚本：仅向渲染层暴露封装好的方法
const { contextBridge, ipcRenderer } = require('electron');
contextBridge.exposeInMainWorld('dbApi', {
  getTodoList: (status) => ipcRenderer.invoke('todo:getList', status)
});

React侧直接调用window.dbApi.getTodoList('all')就能拿到数据，和调普通前端接口的逻辑没有区别。

3. IPC通信方案相比渲染层直连数据库，是否存在性能、安全层面的弊端？ #

• 性能上没有可感知的损耗，实际体验反而比渲染层直连更好。Electron的IPC用结构化克隆做进程间数据传输，普通CRUD场景的额外耗时在亚毫秒级，用户完全感觉不到。而且所有数据库操作都跑在主进程，不会占渲染进程的UI线程，就算是耗时较长的大查询，也不会卡页面。只有单次查询返回几十MB以上数据的时候，IPC的序列化才会出现可感知的延迟，这种场景加个分页查询就能解决。
• 安全上只要按规范做接口收敛、参数校验，IPC方案的安全性比渲染层直连高几个量级，不存在额外风险。唯一要避开的坑就是不要做通用SQL执行通道，只要把IPC接口按业务粒度拆细，就不会有安全问题。

如果你的应用数据库操作特别重、查询逻辑非常复杂，也可以单独开Utility Process承载数据库逻辑，本质还是进程间通信，和主进程持库的逻辑一致，适合重度数据库场景，普通桌面应用直接在主进程跑完全够用。

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