在 Electron 的开发过程中，最影响效率的环节莫过于“改一行代码 → 关闭应用 → 重新打包 → 重启验证”这种低效循环。如果你习惯了前端开发中“保存即刷新”的体验，初次接触 Electron 可能会感到明显的落差。好消息是，经过社区多年的沉淀，现在已经有非常成熟的方案可以让 Electron 开发也拥有接近 Web 开发的热更新体验。
15.3.1 渲染进程的热模块替换（HMR）
渲染进程本质上就是一个网页，因此前端领域的一切热更新手段都可以直接拿过来用。当前最主流的做法是借助 Vite 或 Webpack 的开发服务器来实现热模块替换（Hot Module Replacement，简称 HMR）。
原理简述
启动一个本地开发服务器（如 http://localhost:5173），让渲染进程加载这个地址而不是本地文件。当你修改 Vue/React 组件或 CSS 时，构建工具只替换变更的模块，而不刷新整个页面，组件状态也能得以保留。对于样式修改，甚至连浏览器都不用刷新，新样式立刻生效。
实际操作（以 Vite + Vue 为例）
- 在主进程中，根据
process.env.NODE_ENV判断是否为开发环境。如果是，就让BrowserWindow加载 Vite 的开发服务器地址。
// main.js
const win = new BrowserWindow({ /* ... */ });
if (process.env.NODE_ENV === 'development') {
win.loadURL('http://localhost:5173'); // Vite 默认端口
win.webContents.openDevTools();
} else {
win.loadFile('dist/index.html');
}- 前端项目正常使用 Vite 开发，
vite.config.js无需特殊配置，HMR 开箱即用。
- 启动时，同时运行两个进程：
- Vite 开发服务器（
vite或npm run dev） - Electron 主进程（
electron .）
为了简化启动，通常会使用 concurrently 或 npm-run-all 等工具合并命令，或者直接借助 electron-vite 这类集成工具。
效果
你修改了一个按钮的文字，窗口内容瞬间更新，无需手动刷新；修改了一个 Vue 组件的逻辑，组件重新渲染但全局状态保持不变。这个体验和开发普通 Web 应用完全一致，大幅降低了调试界面的时间成本。
15.3.2 主进程的热更新
渲染进程的 HMR 已经足够舒适，但主进程的改动（如修改窗口行为、菜单、IPC 处理逻辑）仍然需要重启整个应用才能生效，这依旧是一个痛点。所谓“主进程热更新”，其实指的是监听主进程文件变化，自动重启 Electron 应用，而不是真正意义上的模块热替换（因为主进程的状态通常是全局性的，很难做到无状态替换）。
目前社区中有几种主流的实现方式：
方案一：使用 electron-reload 或 nodemon
最简单直接的做法是监视主进程及相关文件，一旦文件变动就杀死当前 Electron 进程并重新启动。
- electron-reload：一个专门为 Electron 设计的 npm 包，它会监视你指定的文件夹，检测到变化后自动调用
app.relaunch()和app.exit()实现重启。
// 在主进程入口文件最顶部引入
require('electron-reload')(__dirname, {
electron: require(`${__dirname}/node_modules/electron`)
});这种方式配置极简，但在项目结构较复杂时可能出现循环监听的副作用，而且每次都是全量重启。
- nodemon：通常用于 Node.js 服务的热重载，也可以用来监视 Electron 主进程文件。配置时指定
exec为electron .，并忽略渲染进程相关目录。
// nodemon.json
{
"watch": ["main.js", "src/main/**/*"],
"ignore": ["src/renderer/**/*"],
"exec": "electron ."
}这种方式的好处是不侵入代码，可靠稳定，适合中小型项目。
方案二：使用 electron-vite 或 electron-forge 集成方案
更现代的工具已经将主进程热更新内置为开发服务器的一部分。
- electron-vite：它借鉴了 Vite 的插件机制，为主进程、预加载脚本和渲染进程都提供了快速的热重载能力。主进程代码通过 esbuild 打包，变动时自动重新编译并在渲染进程连接恢复后重启应用，这一过程通常只需要一两秒。
- @electron-forge/plugin-vite：Electron Forge 的官方 Vite 插件，也提供了类似的开发体验，主进程保存在
src/main下的文件变更会触发 Electron 重启。
这些集成方案是目前推荐的首选，因为它们处理了更多的边界情况（比如 native 模块的重启、多窗口状态保持），并且和渲染进程的开发服务器天然协同。
方案三：手动实现“软重启”
对于追求极致速度的团队，可以自行实现一种“主进程代码热替换”机制：监听文件变化 → 清除 require 缓存 → 重新加载对应模块。但这种方法在 Electron 中风险较高，因为主进程通常持有窗口引用、系统事件监听等状态，简单的模块替换很容易导致状态不一致或内存泄漏。因此绝大多数场景下，自动重启是更稳妥和务实的选择。
15.3.3 完整开发工作流示例
以 electron-vite 为例，一个典型的开发工作流只需执行一条命令：
npm run dev该命令会启动三个子任务：
- Vite 渲染进程开发服务器：提供前端 HMR。
- 主进程的 esbuild watch：监视主进程和预加载脚本，变动时重新编译并通知 Electron 重启。
- Electron 进程：加载上述服务，当主进程重编译完成后会自动退出并重新启动。
你几乎感觉不到编译和重启的延迟，因为 esbuild 的编译速度极快（通常在几十毫秒以内），应用窗口只在瞬间关闭再打开。相比于手动关闭再启动，效率提升非常明显。
15.3.4 常见问题与注意事项
1. 状态丢失问题
主进程重启后，所有窗口状态、内存中的数据都会丢失。如果你的应用依赖主进程中的某些运行时数据（如登录状态、临时缓存），重启会导致信息消失。在设计时要考虑是否将这些状态持久化到本地存储（如 JSON 文件或 electron-store），或者在重启后能快速恢复。
2. 多窗口开发
如果应用同时打开了多个窗口，主进程重启会导致所有窗口一起关闭再重新创建，可能会打断当前的操作流程。一种缓解做法是：在开发时控制只打开一个主要窗口，待功能稳定后再测试多窗口场景。
3. 原生模块和 C++ 插件
如果你在主进程中使用了需要编译的原生模块（如 sqlite3、better-sqlite3），每次变动后重启 Electron 可能仍需重新编译。建议将这些模块的编译产物缓存好，或者使用 electron-rebuild 配合 prebuild-install 加速。
4. 调试体验
主进程重启后，DevTools 通常也会跟着关闭。可以用 --remote-debugging-port 参数保持调试端口开启，或使用 electron-inspector 等工具来持久化调试连接。不过多数简单场景下，重启后手动打开 DevTools 的代价可以接受。
总结来说，现代 Electron 开发已经完全可以享受到“改代码即见效果”的高效体验。渲染进程复用前端 HMR，主进程借助极速编译工具实现秒级重启，两者结合后，你只需要专注于编写业务逻辑，而不再被繁琐的重启过程打断思路。在搭建新项目时，优先考虑使用 electron-vite 或 Electron Forge 的 Vite 模板，它们已经把这些优化内化为标准配置，让你一开始就站在高起点上。