Electron调试需主、渲染进程分别配置：主进程用node类型launch，渲染进程用pwa-chrome类型attach，启动顺序不可颠倒，且必须匹配Node.js v18.15.0–v20.14.0、Electron≥38.1.2及正确的sourceMapPathOverrides。
说实话，很多开发者都以为Electron开发环境搭建是件小事，结果一脚踩进去才发现坑连着坑。虽然它不需要专用的IDE，但想让VSCode真正“驯服”Electron，可不是装个插件那么简单。缺了任意一环，debugger不生效、main.js断点全灰、openDevTools()报错或者直接白屏，这些状况简直是家常便饭。
Node.js 版本必须卡在 v18.15.0–v20.14.0 区间
这里有个常见的误解：Electron ≥38.1.2不是宣称支持Node.js v20吗？没错，但宣称支持和实际稳定运行是两码事。实测下来，v20.14.0是目前最稳妥的上限；一旦跳到v22+，ERR_MODULE_NOT_FOUND或者经典的Cannot find module 'electron'错误就会找上门来。反过来，如果你还停留在v16甚至更早的版本，DEP0148弃用警告就会跳出来，并直接导致进程间通信（IPC）失效。
- 版本管理是第一步：用
nvm切换是最干净的方式，运行nvm install 20.14.0 && nvm use 20.14.0。 - 验证环境：在终端执行
node -v和npm -v，确保npm版本不低于9.5.0。 - 关键一步：项目内必须本地安装Electron（
npm install electron --sa ve-dev）。切记禁用全局安装，否则require('electron')时大概率会找不到模块。
launch.json 必须拆成两个独立配置：主进程 + 渲染进程
这是VSCode调试Electron的核心逻辑，但也是最容易配错的地方。VSCode不支持用单条配置同时附着（attach）两个进程。你必须把它们分开：主进程用node类型来启动（launch），渲染进程则必须走pwa-chrome类型来附着。而且，启动顺序绝对不能颠倒——必须先启动主进程，等应用窗口出现后，再开启DevTools。
- 主进程配置要点：
"type": "node"，"runtimeExecutable": "${workspaceFolder}/node_modules/.bin/electron"（Windows用户记得加.cmd后缀），"args": ["."]。 - 渲染进程配置要点：
"type": "pwa-chrome"，"request": "attach"，"port": 9222。同时，务必确保在主进程中，win.webContents.openDevTools({ mode: 'detach' })的调用是在'ready-to-show'事件之后。 - 一个隐藏陷阱：如果漏掉了
"autoAttachChildProcesses": true这个配置，那么后续创建的子窗口或新的BrowserWindow实例，将完全无法被断点捕获。
ESLint 规则必须区分主/渲染进程环境
代码检查工具如果配置不当，会带来持续的干扰。主进程是纯Node.js环境，自然没有document、window这些浏览器对象；渲染进程默认有DOM，但如果你启用了contextIsolation: true（这是官方推荐的安全设置），那么渲染进程将无法直接访问require或process。如果ESLint不加以区分，要么会批量误报错误，要么会漏掉真正的安全风险。
- 按文件区分环境：在
.eslintrc.cjs中，为不同文件设置env。例如，main.js、preload.js用env: { node: true }；renderer.js或Vue/React组件则用env: { browser: true, es2021: true }。 - 处理全局变量：为了避免
no-undef规则对ipcRenderer的误报，需要在渲染进程的ESLint配置中添加globals: { ipcRenderer: 'readonly' }。 - Preload脚本的兼容性：Preload脚本需要显式处理上下文隔离。像
const { contextBridge, ipcRenderer } = require('electron')这样的引入，最好包裹在if (contextIsolation)的条件分支内，以确保兼容性。
Electron Reload 插件不能替代手动进程控制
很多开发者图省事，会使用electron-reload这类插件来实现文件热更新。它在开发时确实能监听文件变化并重启应用，但问题在于，它的重启方式是“杀死整个主进程再拉起新实例”。这直接导致调试会话中断、所有断点失效、console.log输出丢失。在真实的开发流程中，更可靠的做法是使用concurrently来并行启动多个进程，并配合VSCode的多配置启动方案。
- 脚本配置：在
package.json中配置类似"dev": "concurrently \"npm:electron\" \"npm:watch\""的脚本，其中electron脚本可以设置为electron . --inspect=9229。 - 避免过早打开工具：切忌在
main.js一开头就调用openDevTools()。如果窗口还没准备好就弹窗，很可能会遇到Cannot read property 'openDevTools' of null这样的错误。 - 真正的“热重载”：对于渲染进程的代码修改，最可靠的热更新路径其实是：修改代码 → 保存 → 在窗口内按
Ctrl+R刷新。这仅仅是刷新了当前窗口，而非重启整个Electron进程，因此不会打断调试状态。
说到底，Electron调试从来不是“一次性配好就能高枕无忧”的事情。它要求你对齐进程模型、V8协议版本、Chromium构建参数等一系列复杂因素。其中，sourceMapPathOverrides配置缺失是最容易被忽略的一环——当你使用Vite或Webpack打包渲染进程代码时，如果这个字段没映射对，就会出现“断点明明打在源码上，却停在了编译后的bundle文件里”这种令人困惑的情况。这才是调试链路最终能否打通的关键所在。
