2、上下文隔离（Context Isolation）：原理、启用方式、与预加载脚本的配合

上下文隔离，我把它叫做 Electron 安全的第一道防线。说白了，就是把渲染进程和 Node.js 环境彻底隔开。你想想看，如果没有这道墙，网页里的恶意脚本就能直接调用 require('child_process')，那你的电脑就跟裸奔一样。

2.1 为什么需要上下文隔离？

在 Electron 早期版本，渲染进程默认能访问 Node.js API。这确实方便，但也带来了巨大的安全隐患。我记得有个项目，团队为了方便，直接在渲染进程里用了 fs 模块读写文件。结果呢？一个 XSS 漏洞就让攻击者拿到了服务器上的敏感数据。

上下文隔离的核心思路很简单：

• 渲染进程运行在独立的 V8 上下文中
• 无法直接访问 require、process、Buffer 等 Node.js 对象
• 只能通过预加载脚本暴露的有限接口与主进程通信

2.2 启用方式

启用上下文隔离非常简单，在创建 BrowserWindow 时设置 contextIsolation: true 即可。嗯，这里要注意，从 Electron 12 开始，这个值默认就是 true，但你最好显式声明，让代码意图更清晰。

const { BrowserWindow } = require('electron')

const win = new BrowserWindow({
  width: 800,
  height: 600,
  webPreferences: {
    contextIsolation: true,  // 开启上下文隔离
    nodeIntegration: false,  // 关闭 Node.js 集成
    preload: path.join(__dirname, 'preload.js')
  }
})

2.3 预加载脚本的配合

上下文隔离开启后，渲染进程就变成了一个「干净」的浏览器环境。那怎么跟主进程通信呢？答案就是预加载脚本。

预加载脚本运行在一个特殊的环境中——它既有渲染进程的 DOM 访问权限，又能通过 contextBridge 安全地暴露 API。我个人习惯把预加载脚本看作「桥梁」，它只传递必要的数据，绝不暴露整个 Node.js 能力。

2.3.1 使用 contextBridge 暴露 API

// preload.js
const { contextBridge, ipcRenderer } = require('electron')

contextBridge.exposeInMainWorld('electronAPI', {
  // 暴露一个安全的文件读取方法
  readFile: (filePath) => ipcRenderer.invoke('read-file', filePath),
  
  // 暴露一个版本信息
  appVersion: process.env.npm_package_version,
  
  // 暴露一个事件监听
  onUpdateAvailable: (callback) => {
    ipcRenderer.on('update-available', (event, data) => {
      callback(data)
    })
  }
})

在渲染进程中，你就可以这样使用：

// renderer.js
const version = window.electronAPI.appVersion
console.log('App version:', version)

// 调用文件读取
const content = await window.electronAPI.readFile('/path/to/file')

2.3.2 预加载脚本的注意事项

这里有几个坑，我踩过，你最好别踩：

• 不要暴露整个 ipcRenderer：只暴露具体的方法，比如 invoke('read-file')，而不是 ipcRenderer.invoke。否则攻击者可以调用任何 IPC 通道。
• 参数校验不能少：预加载脚本收到的参数可能来自恶意网页，一定要做类型检查和范围限制。
• 避免暴露同步方法：同步 IPC 会阻塞渲染进程，用户体验极差。我一般只用 invoke 和 on。

2.4 上下文隔离的工作原理

你可能好奇，上下文隔离到底是怎么实现的？简单来说，Electron 为每个渲染进程创建了两个 V8 上下文：

上下文	可访问内容	用途
主上下文	DOM API、JavaScript 标准库	运行网页代码
隔离上下文	Node.js API、Electron API	运行预加载脚本

这两个上下文之间通过 contextBridge 进行安全通信。说白了，就是预加载脚本在隔离上下文里定义好接口，然后通过 exposeInMainWorld 复制到主上下文。注意是「复制」，不是「引用」——所以主上下文无法修改隔离上下文里的对象。

2.5 实战：一个安全的文件查看器

让我用一个实际例子来演示。假设我们要做一个安全的文件查看器，用户只能查看特定目录下的文件：

// preload.js
const { contextBridge, ipcRenderer } = require('electron')

contextBridge.exposeInMainWorld('fileViewer', {
  // 只允许查看 /data 目录下的文件
  readFile: async (filename) => {
    // 参数校验：只允许字母数字和 . 符号
    if (!/^[\w.]+$/.test(filename)) {
      throw new Error('Invalid filename')
    }
    return ipcRenderer.invoke('read-file', filename)
  },
  
  listFiles: async () => {
    return ipcRenderer.invoke('list-files')
  }
})

// main.js
ipcMain.handle('read-file', async (event, filename) => {
  const safePath = path.join(__dirname, 'data', filename)
  // 防止路径穿越攻击
  if (!safePath.startsWith(path.join(__dirname, 'data'))) {
    throw new Error('Access denied')
  }
  return fs.readFileSync(safePath, 'utf-8')
})

你看，即使渲染进程被 XSS 攻击，攻击者也只能调用 fileViewer.readFile，而且参数还被严格限制。这就是上下文隔离 + 预加载脚本的威力。

2.6 常见问题与避坑指南

最后，分享几个我实际项目中遇到的问题：

• 问题：预加载脚本中的 console.log 看不到输出
  原因：预加载脚本运行在隔离上下文，控制台输出需要开启 webPreferences.contextIsolation: true 并查看 DevTools 的「预加载脚本」控制台。
• 问题：暴露的对象在渲染进程中是 undefined
  原因：可能是预加载脚本加载顺序问题。确保 preload 路径正确，且脚本没有语法错误。
• 问题：性能开销
  我曾经担心上下文隔离会带来性能损失。实测下来，对于大多数应用，这个开销可以忽略不计。如果你在做高频通信，可以考虑批量传输数据。

好了，上下文隔离就讲到这里。下一章我们会聊「进程沙盒化」，那是比上下文隔离更底层的安全机制。到时候见。