Electron渲染进程原生支持ESM，但需通过preload脚本+contextBridge暴露IPC接口才能安全通信；直接import electron模块被禁止，主进程ESM与渲染进程ESM仍依赖IPC通道交互。
Electron 渲染进程原生支持 ESM（ECMAScript Module），但能否直接用 import 加载 Node.js 或 Electron 模块，取决于渲染进程的配置——尤其是 上下文隔离（contextIsolation） 和 沙盒（sandbox） 状态。原生 ESM 通信本身不直接“传输数据”，它影响的是你如何安全地组织和暴露 IPC 接口。
渲染进程启用原生 ESM 的前提条件
要在渲染进程中使用 type="module" 的脚本或 .mjs 文件，需满足：
- HTML 中 script 标签必须显式声明
type="module"：<script type="module" src="renderer.mjs"></script> - 或 JS 文件以
.mjs结尾，并在webPreferences.preload中正确指定（若用于 preload） - Chromium 加载器生效：非沙盒化渲染进程下，ESM 由 Chromium 解析；沙盒化渲染进程中，ESM preload 不被支持
为什么不能在渲染进程里直接 import electron？
因为 Electron 的 ipcRenderer 等模块默认不可在渲染进程全局作用域访问——这是安全限制。即使启用了 ESM，你仍需通过 preload 脚本 + contextBridge 暴露受控 API：
- preload.js（必须是 CommonJS 或 ESM，但需适配沙盒规则）中，用
contextBridge.exposeInMainWorld定义一个干净的 IPC 封装对象 - renderer.mjs 中只能
import这个已暴露的全局对象（如window.api），不能import { ipcRenderer } from 'electron' - 示例：
— preload.mjs（非沙盒、上下文隔离开启）：import { contextBridge, ipcRenderer } from 'electron';<br>contextBridge.exposeInMainWorld('api', {<br> send: (channel, data) => ipcRenderer.send(channel, data),<br> receive: (channel, cb) => ipcRenderer.on(channel, cb)<br>});
— renderer.mjs：import { api } from './utils/ipc.js'; // 或直接用 window.api<br>api.send('log', 'hello from ESM');
主进程与渲染进程的 ESM 兼容通信模式
主进程可天然使用 ESM（如 main.mjs + "type": "module"），但渲染进程的 ESM 脚本无法直连主进程。真正起作用的仍是 IPC 通道，ESM 只负责调用方式：
立即学习“Java免费学习笔记（深入）”；
- 异步通信（推荐）：
渲染进程 ESM 调用window.api.send('save-file', content)→ 主进程ipcMain.on('save-file', ...)处理 → 再用event.reply()返回 - 避免同步通信（
sendSync）：
ESM 环境下同步阻塞更易引发 UI 卡顿，且在上下文隔离+沙盒组合下已被禁用 - 消息通道名保持字符串字面量（如
'file:open'），不依赖模块路径，确保主/渲染两端解耦
常见陷阱与绕过建议
以下情况会导致 ESM 渲染脚本 IPC 失效：
-
启用了 sandbox: true：此时 preload 无法 require 或 import
electron，必须关闭 sandbox 或改用webview+guestinstance方案 -
contextIsolation: false 且未设 preload：虽可直接
require('electron')，但违反 Electron 安全最佳实践，不推荐 -
preload 使用 .mjs 但未在 BrowserWindow 中正确声明：确保
webPreferences.preload指向preload.mjs，且该文件有对应 ESM 配置
