vscode配置electron开发必须配齐四要素：node.js v20.14.0 + electron ≥38.1.2、本地安装electron、launch.json双进程调试（主进程node+渲染进程pwa-chrome）、eslint按环境区分；缺一则断点灰、ipc失效或白屏。
VSCode 本身不支持 Electron 开发开箱即用，必须手动配齐 Node.js 版本、本地 Electron 安装、launch.json 双进程调试配置、ESLint 环境区分这四块——缺一不可，否则断点灰掉、ipcRenderer 报错、openDevTools() 白屏都是常态。
Node.js 和 Electron 版本必须严格匹配
当前最稳组合是 Node.js v20.14.0 + Electron ≥38.1.2。v22+ 会直接触发 ERR_MODULE_NOT_FOUND；v16 或更早则报 DEP0148 警告并让 IPC 失效。
- 用
nvm install 20.14.0 && nvm use 20.14.0切换版本，再执行node -v和npm -v验证（npm ≥9.5.0） - 项目内必须
npm install electron --save-dev，禁用npm install -g electron—— 全局安装会导致require('electron')找不到模块 - 建议设镜像：在项目根目录写
.npmrc，内容为ELECTRON_MIRROR=https://npmmirror.com/mirrors/electron/，避免安装卡死
launch.json 必须拆成两个独立调试配置
VSCode 不支持单条配置同时 attach 主进程和渲染进程。主进程走 node 类型，渲染进程必须用 pwa-chrome 类型，且启动顺序不能颠倒：先跑主进程，等窗口出现后再 attach 渲染进程。
Miller (mlr) 是一个命令行工具，用于查询、整形和重新格式化名称索引数据，如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。
- 主进程配置关键项：
"type": "node"，"runtimeExecutable": "${workspaceFolder}/node_modules/.bin/electron"（Windows 加.cmd后缀），"args": ["--inspect=9229", "."]—— 注意--inspect=9229必须在.前面，否则 Electron 直接忽略 - 渲染进程配置关键项：
"type": "pwa-chrome"，"request": "attach"，"port": 9222；主进程中需在'ready-to-show'事件后调用win.webContents.openDevTools({ mode: 'detach' }) - 别加
"autoAttachChildProcesses": true，它会让新BrowserWindow的渲染进程调试失效
ESLint 必须按进程环境区分规则
主进程是纯 Node.js 环境，不能用 document、window；渲染进程虽有 DOM，但若启用 contextIsolation: true（推荐），就无法直接访问 require 或 process。ESLint 若不区分，会批量误报或漏报安全风险。
- 在
.eslintrc.cjs中为不同文件设置env：env: { node: true }用于main.js、preload.js；env: { browser: true, es2021: true }用于renderer.js或 Vue/React 组件 - 渲染进程需显式声明
ipcRenderer全局变量，加globals: { ipcRenderer: 'readonly' }消除no-undef误报 -
preload.js中必须用const { contextBridge, ipcRenderer } = require('electron')显式桥接，否则contextIsolation下 IPC 会静默失败
真正容易被忽略的不是配置项数量，而是模块系统路径匹配和进程间环境隔离——比如 main.js 里 app 是 undefined，往往不是代码写错了，而是 runtimeExecutable 指向了全局 electron 命令，导致 VSCode 启动的 Electron 版本和项目实际依赖的版本不一致。
