Electron上下文隔离与进程沙箱，隔离的对象并不相同

桌面应用资料中，“开启隔离”有时被用来概括多个设置。对Electron而言，上下文隔离和进程沙箱各自描述不同层次。只留一个没有对象的“隔离”标签，会使读者无法知道具体核对过哪项机制。

Electron的Context Isolation文档说明，preload脚本和Electron内部逻辑，与加载的网站运行在不同上下文。原文用window对象解释：preload能够访问的对象，与页面能够访问的并非同一个。这里强调的是JavaScript执行上下文的边界。

Process Sandboxing文档则介绍进程沙箱对系统资源访问的限制；需要额外权限的工作，涉及向更有权限的进程委托。文中也说明，沙箱化的渲染进程不会初始化通常的Node.js环境。这个层次与页面能否直接访问preload的JavaScript对象，不能合并成同一个问题。

默认启用时间也不同。官方分别将上下文隔离默认启用的起点写为Electron 12，将渲染进程沙箱默认启用的起点写为Electron 20。引用版本时，应让数字跟随各自机制，不把一项的起点复制到另一项，更不能用默认说明证明某个实际应用当前一定保持了默认状态。

公开文档还明确提醒，仅启用contextIsolation并使用contextBridge，并不自动使应用的所有做法都安全。本稿采用这一范围限制，但不展开代码示例或接口暴露方案。实际安全评估仍需要针对应用行为及构造，不是从两个选项名称推得结论。

如果团队整理一份架构说明，可以分别记录所用Electron版本、JavaScript上下文边界的说明，以及渲染进程沙箱的相关资料。某项只依据官方默认行为，另一项已有项目审查记录，也应明确区分，不能将两种证据等级都写成“实测通过”。

本文没有加载任何应用或检查发布配置，不提供关闭隔离、调整权限或绕过沙箱的方法，也不对未知应用作安全评价。它仅帮助读者读准两个技术名称：上下文隔离与进程沙箱可以共同出现在架构中，但各自回答的隔离对象不同，最终应用安全还需要独立专业审查。