我最初认为 Electron 中的渲染器进程在类似 chrome 的环境中被沙箱化，这意味着你所能做的就是弄乱 DOM。但是，我最近了解到您可以访问文件系统、运行子进程并获取它们的输出，并导入您想要的任何其他节点模块。
如果是这样的话，主进程和渲染进程的区别到底是什么？不是硬分离吗？什么样的代码进入主进程，什么样的代码进入渲染进程？
如果有人对 Electron 应用架构有很好的深入阅读/演示，我也很想看看；可能有助于消除一些困惑
【问题讨论】：
标签： electron
主/渲染进程的区别实际上并不是一个 Electron 概念本身——它是从 Chromium 继承的（这里是关于 Chromium 架构的article 及其背后的推理）。这是 Chrome 出于性能和稳定性原因而使用的架构。每个 webContents 实例都在它自己的进程中运行（“渲染器”进程）。主进程（只能是其中一个）管理 webContents 实例等。
关于两者之间的差异有一个good discussion here。
某些 API 仅在一个进程或另一个进程中可用，这可以帮助您了解逻辑在哪里。例如，通知（使用 HTML5 接口，但作为原生通知实现）只能从渲染器进程创建。 Menu class 只能从主进程中调用。通读 Electron 模块的 API 文档，看看哪里有什么。您可以使用IPC、remote 模块或electron-remote 在两个进程之间进行协调（使用哪一个取决于您的用例）。
我会说这是一个“硬”分离。它们都是独立的进程，因此不共享任何资源或状态。对于我认为的大多数 JS 开发人员来说，这是一种范式转变（至少对我来说是这样）。例如，如果我有一个有状态的模块，我在主进程中设置了一些状态，然后我在渲染器中需要该模块，那么该状态将不存在。它们是该模块的两个完全不同的实例。像这样共享状态可能最好在主进程中，然后使用上述方法之一在渲染器进程之间共享该状态。
这里是real life apps 和some sample apps. 的列表
Shawn Rakowski 说得好（在下面的 cmets 中）：“将处理平台基础架构代码（即创建窗口、注册全局快捷方式等）的代码放在主进程和应用程序特定代码中可能是一个很好的规则（你的应用实际在做什么）在渲染器进程中。”
[我的应用的功能是什么]解析一些文件，然后将信息呈现到屏幕上
在 Electron 中有很多方法可以解决这个问题，因为在渲染器进程中可以使用 fs 模块（以及所有 node.js 模块）。
如果您只处理一个浏览器窗口实例而不进行 CPU 密集型解析，我会说在该渲染器进程实例中运行所有 fs 相关代码。这是最简单的方法。
如果您在这些文件上执行 CPU 密集型工作，您不想锁定 UI，这意味着您无法执行处理浏览器窗口渲染器，也无法在 main (这将锁定你所有的渲染器！）。所以我会研究electron-remote 之类的东西，或者创建一个不可见的浏览器窗口实例来运行繁重的工作。
这篇关于main and renderer processes 的文章更深入地讨论了这些主题（披露：我写的）。
【讨论】：