Electron 让前端开发者可以用熟悉的 Web 技术（HTML/CSS/JS）构建跨平台的桌面应用（VS Code, Slack, Discord 均基于此）。但从 Web 到桌面端的跨越，核心难点在于进程模型、IPC 通信以及性能与安全的平衡。

本文将深入 Electron 的底层机制，剖析如何优雅地实现前端与原生的交互，并分享生产环境下的性能优化策略。

TL;DR

• 进程模型：主进程（Main）负责系统级操作，渲染进程（Renderer）负责 UI。永远不要阻塞主进程。

• 通信进化：弃用 remote 模块，全面拥抱 contextBridge + ipcRenderer.invoke 的双向通信模式。

• 安全第一：开启 contextIsolation 和 sandbox，禁止在渲染进程直接使用 Node.js API。

• 性能关键：控制包体积，延迟加载原生模块，使用骨架屏掩盖启动耗时。

1. 核心架构：主进程与渲染进程

Electron 的架构继承自 Chromium，采用多进程模型：

主进程 (Main Process)

• 职责：管理应用生命周期、创建窗口 (BrowserWindow)、调用原生 API (文件、系统托盘、菜单)。

• 特点：拥有完整的 Node.js 环境，只有一个。

• 避坑：主进程是整个应用的“指挥官”，绝对禁止执行 CPU 密集型任务，否则会导致整个应用无响应。

渲染进程 (Renderer Process)

• 职责：展示 UI 界面，运行 Web 页面。

• 特点：每个窗口对应一个渲染进程（通常情况下）。出于安全考虑，现代 Electron 默认禁用了渲染进程的 Node.js 集成。

2. 前端与原生交互：IPC 通信的演进

2.1 过去：Remote 模块（已废弃）

早期 Electron 允许渲染进程直接通过 remote 调用主进程对象（如 remote.require('fs')）。

问题：同步调用导致渲染进程阻塞；存在巨大的安全漏洞；对象引用导致内存泄漏。

2.2 现在：ContextBridge + Invoke/Handle

这是目前官方推荐的最佳实践。通过 preload.js 搭建一座安全的桥梁，将特定的 API 暴露给渲染进程。

Main Process (主进程)

在 React、Vue、Angular 三分天下的今天，组件化开发早已深入人心。但你是否遇到过这样的场景：公司内部既有 Vue2/3 项目，也有 React 项目，还需要维护一些 jQuery 老系统。为了保持 UI 风格统一，难道要为每个框架都写一套组件库吗？

Web Components 提供了一种标准化的解决方案：它允许你创建可重用的自定义元素，这些元素在任何框架中都能像原生 HTML 标签一样工作。本文将带你从零实现一个 Web Component，并探讨其在微前端与跨框架场景下的应用。

TL;DR

核心三剑客：Custom Elements（自定义标签）、Shadow DOM（样式隔离）、HTML Templates（结构复用）。

生命周期：connectedCallback（挂载）、disconnectedCallback（卸载）、attributeChangedCallback（属性变化）。

跨框架：在 Vue 中直接用 <my-btn>，在 React 中需处理自定义事件的兼容性。

最佳实践：推荐使用 Lit 等轻量库简化开发，而非裸写原生 API。

1. 原生实现：手写一个 UserCard 组件

我们来实现一个 <user-card> 组件，支持 avatar 和 name 属性，且样式不被外部污染。