沙箱（Sandbox）是 Electron 安全模型中最后也是最强的一道防线。自 Electron 20 起，沙箱模式默认开启，渲染进程仅拥有浏览器级别的权限，无法直接触碰任何 Node.js 或系统资源。这从根本上改变了渲染进程的能力边界——同时也极大地提升了应用的整体安全性。
5.5.1 什么是沙箱模式
简单来说，沙箱模式就是剥夺渲染进程的所有系统级权限，让它退化为一个标准的浏览器环境。在沙箱开启的渲染进程中：
require不再可用，无法引入 Node.js 模块。- 无法直接调用 Electron 的原生 API（如
shell、clipboard、ipcRenderer等，除非通过 preload 安全暴露）。 - 不能访问文件系统、操作系统接口、子进程等任何危险能力。
渲染进程唯一能做的，就是渲染 HTML/CSS/JavaScript，以及在用户交互下执行网页逻辑。所有对系统资源的访问都必须“绕道”主进程，通过预先定义好的 IPC 通道进行。
5.5.2 能力限制的具体表现
开启沙箱后，你会在开发中明显感受到以下几点变化：
1. 无法直接引入原生模块
// ❌ 沙箱下会直接报错
const fs = require('fs');
const { shell } = require('electron');如果你试图在渲染进程中执行以上代码，应用会抛出一个 Uncaught Error: require is not defined 异常（如果 nodeIntegration 关闭），或者即使 require 可用也无法加载这些模块（沙箱阻断具体实现）。
2. 所有系统交互必须走主进程
任何文件读写、系统对话框、网络请求（如果需要在主进程侧做代理）、原生命令执行，都必须通过 IPC 转发给主进程，再由主进程完成。例如，想获取用户目录路径：
// preload.js
contextBridge.exposeInMainWorld('api', {
getUserPath: () => ipcRenderer.invoke('get-user-path'),
});
// main.js
ipcMain.handle('get-user-path', () => app.getPath('home'));
// renderer.js
window.api.getUserPath().then(console.log);直接调用 app.getPath 在渲染进程中将完全不可行。
3. 不允许使用 eval 和 Function 动态执行脚本（默认 CSP 下）
沙箱与 Content Security Policy 配合时，通常会禁止 eval 和 new Function，这堵死了攻击者注入动态代码的路径。如果你确实需要类似功能，必须显式、谨慎地在 CSP 中放开，但强烈不推荐。
4. 无法创建子进程或访问系统底层child_process、process 的许多属性在沙箱渲染进程中都不可用，即使强行引用也会被屏蔽。这使得恶意脚本无法在本地执行系统命令。
5.5.3 安全增益
沙箱的限制不是阻碍开发的障碍，而是用“最小权限原则”将攻击面压缩到极致。
1. 杜绝远程代码执行（RCE）的致命后果
假设你的应用加载了第三方网页，或者因为 XSS 漏洞被注入了恶意脚本。在没有沙箱的情况下，攻击者可以直接调用 require('child_process').exec('rm -rf /')（在 macOS/Linux 上）或同等破坏性命令。而在沙箱模式下，即使渲染进程被完全控制，它也拿不到任何系统权限——它连 require 都找不到，更别提执行危险操作了。沙箱把潜在的安全漏洞变成了只影响当前页面的“浏览器级”问题。
2. 隔离不同窗口的资源访问
每个渲染进程都是独立的沙箱实例，一个窗口被攻破不会影响另一个窗口。比如你的应用有主界面和设置窗口，即使设置窗口因为加载了不安全的远程内容而沦陷，攻击者也无法跳跃到主界面进程去读取数据或修改配置。
3. 强制实现权限分离的架构
因为什么事都得找主进程，你会自然地形成权限分明的代码结构：渲染进程只管界面，主进程负责一切系统交互。这种模式逼着开发者在设计时就想清楚“我的窗口到底需要哪些能力”，从而避免图省事直接将 Node.js 全量暴露给 UI 层。久而久之，你的代码会变得更安全、更易维护。
4. 配合 CSP 和 Context Isolation 形成多层防御
沙箱不是单打独斗。它与上下文隔离（Context Isolation）、内容安全策略（CSP）共同组成了一个三层防护体系：
- CSP 阻止渲染进程加载未授权的脚本和资源。
- Context Isolation 确保 preload 和网页代码运行在不同世界，避免网页直接篡改暴露的 API。
- 沙箱则直接拔掉渲染进程的底层权限牙。
即使前两层失效，沙箱依然能兜底，防止攻击者获得真正的系统能力。
5.5.4 使用沙箱的现实考量
在真实项目中，开启沙箱可能会让你觉得“束手束脚”，尤其是当你习惯了在渲染进程里随手 require('fs') 的时候。但这种不便是值得的，而且可以通过合理的 preload 设计和主进程服务优雅地解决。
推荐的实践路径：
- 始终开启沙箱（Electron >= 20 已默认开启），不要手动关闭
sandbox: false。 - 如果某个操作感觉必须由渲染进程完成（例如文件解析库），将它挪到主进程，通过 IPC 返回结果。
- 如果性能敏感（大量数据交互），使用
MessagePort或共享内存（Uint8Array+postMessage）避免序列化瓶颈，但 权限操作仍然必须主进程完成。
唯一的代价：IPC 通信会带来微小的性能开销和代码量增加。但对任何严肃的应用来说，与阻止一次致命攻击相比，这些开销完全可以忽略。当你看到安全公司报告“某 Electron 应用 RCE 漏洞可执行系统命令”时，几乎无一例外都是因为关闭了沙箱并合并启用了 Node Integration。
一句话总结： 沙箱模式把渲染进程的权限压缩到和普通浏览器页面一样的级别，让任何入侵的恶意代码都束手无策。它不是开发效率的绊脚石，而是一道用极低成本换来的、能够将严重安全事件降级为无害页面的终极防护。