Electron 的本质是将 Chromium 与 Node.js 进程协同运行，主进程负责系统 API（如窗口管理、文件读写），渲染进程负责 UI 渲染，二者通过 IPC 通信；它不编译 JS，也不改造语言本身，而是填补前端 JS 调用操作系统能力的空白。
Electron 不是“让 JavaScript 能开发桌面应用”的原因，而是把 Chromium 和 Node.js 进程绑在一起运行——JavaScript 本身早就能做桌面应用，只是缺一个带完整系统 API 的运行时环境。
Electron 的核心其实是两个进程在协同
它不是把 JS 编译成原生代码，也不改 JS 语言本身。主进程跑 Node.js，负责窗口管理、系统对话框、文件读写等；渲染进程跑 Chromium，负责界面渲染和用户交互。两者通过 ipcMain / ipcRenderer 通信。
- 主进程用
BrowserWindow创建窗口，每个窗口对应一个独立的渲染进程 - 渲染进程默认禁用
Node.js集成（出于安全），需显式开启nodeIntegration: true或用contextBridge暴露有限能力 - 直接在渲染进程里调
require('fs')会报错，除非配置了nodeIntegration且没启用contextIsolation
为什么不能只用 Chromium 或只用 Node.js
纯 Chromium（比如用 chrome --app=）没法访问文件系统、注册全局快捷键、托盘图标或原生菜单；纯 Node.js（比如用 node + express）只能起个本地服务，还得靠浏览器打开，不是真正意义上的“桌面应用”。
Handsfree Windows Control
下载
通过 handsfree-windows CLI控制 Windows 本机应用 (UIA) 和浏览器 (Playwright) 的引导技能，用于自动化或测试桌面应用。
- Electron 补的是“前端 JS 能否调操作系统能力”这个缺口
-
electron-builder打包时会把Chromium和Node.js二进制一起塞进 app 目录，所以体积大（通常 >100MB） - Windows 上若用
app.disableHardwareAcceleration()，可能解决黑屏或卡死，但 UI 动画会变卡
常见启动失败错误和对应检查点
运行 electron . 报错，多数不是代码问题，而是环境或配置偏差。
立即学习“Java免费学习笔记（深入）”；
-
Error: Cannot find module 'electron'：确认electron是devDependencies，且没被误装到dependencies -
Failed to load module script: Expected a JavaScript module script but the server responded with a MIME type of "text/plain"：检查 HTML 中type="module"脚本是否用了相对路径，或 dev server 没配好 MIME 类型 - 空白窗口无报错：大概率是
mainWindow.loadFile()路径写错，或index.html里 JS 报错阻塞了执行（开mainWindow.webContents.openDevTools()看 Console）
真正难的不是“怎么跑起来”，而是搞清哪段代码该放主进程、哪段必须放渲染进程、通信时要不要序列化、如何避免远程代码执行漏洞——这些边界一旦模糊，调试成本会指数上升。
