沙箱（sandbox）是 Chromium 提供的一种安全机制，它能将渲染进程运行在一个受到严格限制的环境中：即使网页或渲染进程中的脚本存在漏洞，攻击者也很难突破沙箱去操作操作系统级别的资源，比如读写任意文件、执行系统命令或访问其他进程的内存。Electron 很早就支持开启沙箱，但从实际项目来看，很多应用出于惯性仍然在禁用沙箱的模式下运行。
为什么你要认真对待沙箱
在没有沙箱的情况下，渲染进程默认拥有较高的系统权限（视你暴露的 Node.js 或 Electron API 而定）。一旦你的渲染进程被成功攻击，比如加载了包含恶意代码的第三方网页，或者某个依赖库被植入了脚本，这些代码就能够直接调用 Node.js 的 require，然后做什么都不奇怪——读取本地文件、上传敏感信息、删除目录，甚至通过 child_process 执行系统命令。沙箱的作用就是把这道门提前焊死，让渲染进程只能做“展示界面”这一件事。
开启沙箱的具体操作
从 Electron 20 开始，框架已经默认开启了 sandbox: true。但考虑到实际项目中你可能会维护一些老项目，或者你使用的模版仍然在显式地关闭它，你应当主动检查并确保它是开启的。
在创建窗口的 webPreferences 中，加入以下配置：
const win = new BrowserWindow({
webPreferences: {
sandbox: true, // 开启渲染进程沙箱
contextIsolation: true, // 几乎总是与 sandbox 一起使用
preload: path.join(__dirname, 'preload.js'),
},
});sandbox: true是开启沙箱的核心开关。它会限制渲染进程对系统资源的访问，无论你是否在渲染进程中试图使用 Node.js。contextIsolation: true必须同时开启（Electron 12+ 已经默认开启）。它确保了预加载脚本和网页内容运行在不同的 JavaScript 上下文中，防止网页代码直接访问require等危险对象。
如果你还在使用旧版本的 Electron，需要确认版本是否支持 sandbox 选项，并强烈建议升级到最新稳定版以享受默认的安全配置。
开启后不可用的 API 和应对方法
开启沙箱后，渲染进程中将无法直接使用 Node.js 的核心模块（如 require('fs')）、不能使用 Electron 的原生模块（如 require('electron')），也无法在开发者工具的控制台中直接执行 require。这是设计上的故意限制——既然渲染进程的任务是展示界面，它就不该拥有这些危险能力。
那么原本在渲染进程中要完成的系统级操作怎么办？全部迁移到主进程，通过预加载脚本暴露有限的、受控的接口：
// preload.js
const { contextBridge, ipcRenderer } = require('electron');
contextBridge.exposeInMainWorld('myAPI', {
// 只暴露一个安全的“打开文件”方法，不暴露整个 fs 或 Node.js
openFile: () => ipcRenderer.invoke('dialog:openFile'),
});主进程收到请求后，在拥有完整权限的环境下执行 dialog.showOpenDialog，然后把结果返回。这样一来，即便网页内容被篡改，攻击者能做的也只是调用你提前定义好的有限几个方法（比如弹出文件对话框），而无法随意访问整个文件系统。
一个常见误区：把 Node.js 集成当成“便捷”
很多老旧教程会指导你设置 nodeIntegration: true 和 contextIsolation: false，然后在渲染进程中直接写 const fs = require('fs')。这种写法虽然看起来直接，但它等于放弃了沙箱保护，将所有 Node.js 的能力都暴露给网页内容。在沙箱模式下，这种用法会被完全禁止。如果项目里已经有这种代码，就要逐步将它们迁移到 IPC 模型中，这也是现代 Electron 应用安全改造的第一步。
验证沙箱是否真的生效
你可以通过一个简单的方法来验证：在渲染进程的 DevTools 控制台中输入 process 或者 require，如果返回 undefined 或抛出错误，说明上下文隔离和沙箱正在正常工作。你也可以使用 app.getAppPath() 这样更直接的系统调用测试——沙箱下的渲染进程没有访问权限，应该会失败。
另外，Electron 官方提供的安全检测工具 electronegativity 可以自动扫描你的代码库，指出哪些地方还在依赖不安全的 nodeIntegration 或未开启沙箱的配置。
开启沙箱对第三方库的影响
一些比较老的 npm 包可能假设自己运行在完整 Node.js 环境下（比如直接在渲染进程中调用 require('child_process')），在沙箱中会直接报错。如果你在集成第三方组件（如 PDF 查看器、视频播放器、某些编辑器控件）时遇到“模块未定义”的错误，优先检查该库是否依赖 Node.js，并寻找纯前端版本的替代品，或者修改其逻辑改为通过 IPC 调用。
总之，开启沙箱模式不是可选项，而是安全地使用 Electron 的基本前提。它不复杂，多出的那一点 IPC 代码在工程上也是清晰的职责分离的体现。如果你正启动一个新项目，记得从第一个窗口起就保持 sandbox: true 和 contextIsolation: true 开启；如果是维护现有项目，就把这项改造列入优先的迭代计划。