Vite+Electron构建仿微信桌面聊天系统全流程实践-平芜编程栈

我印象很深，半年前手上有个内部工具一直跑在浏览器里，每次开会演示都得先开后台、再找 URL、还得祈祷缓存别捣乱。被恶心了几次之后我下了决心：把它搬成一个桌面端应用。正好那段时间一直在折腾聊天类 UI，干脆就拿“仿微信桌面端聊天系统”当练手项目，技术栈直接选了 Vite + Electron。这套组合做完之后我的感受是：Electron 仍然是做跨平台桌面端最稳妥的选择，而 Vite 能把它前端的开发体验拉到接近 Web 项目的水平。这篇就把整个项目从选型到落地的完整过程写出来，包括工程化搭建、窗口设计、聊天数据流、打包与性能优化，以及我实际踩过的坑。想入坑 Electron 的前端同学，或者正在纠结桌面端技术选型的朋友，可以参考。

1. 技术选型复盘：为什么最终是 Vite + Electron 这个组合

很多朋友一上来就问我：做个桌面聊天软件，为什么不用 Tauri？为什么不用 C# 或者 Qt？这里我把自己的对比思路完整摆出来，顺便解释一下 Electron 在这个场景下到底不可替代在哪。

1.1 四种桌面端方案的横向对比

先给一张我当时的选型对比表，参数是我的真实体验，不代表绝对权威，但很有参考价值。

方案	技术栈要求	安装包体积	内存占用	跨平台一致性	生态成熟度
Electron	前端技术栈即可	较大，约 60MB+	中高	高	极高
Tauri	需要会 Rust，前端部分不变	很小，约 5MB	低	高，但底层坑偏多	中
C# WinForms/WPF	需要 .NET 技术栈	中等	低	仅限 Windows	中高
Qt	需要 C++ 或 Python	中等	中等	高	高

对于我这个纯前端背景、而且希望“一个代码库同时覆盖 Windows 和 macOS”的人来说，Electron 几乎是唯一答案。C# 直接排除，因为跨平台就过不了；Qt 虽然有 PySide 这种 Python 绑定，但复杂的界面布局写起来完全没有前端顺手，尤其做仿微信这种像素级 UI 会非常痛苦。Tauri 我确实认真考虑过，也跑过 demo，最后还是退了，原因是团队的 Rust 水平不足以支撑日常开发排错，再加上它依赖系统 WebView，不同系统上的兼容性问题比 Electron 多一个数量级。做产品要的是稳定交付，不是给自己增加排错负担。

1.2 Vite 在 Electron 开发里解决了什么真问题

Electron 的老玩家应该都经历过 Webpack 时代：改一行样式，等编译、等热更新、再等窗口刷新，一顿操作下来半分钟没了。Vite 带来的第一个革命性体验就是开发服务器启动快到几乎是瞬间的，因为它用原生 ES Module 按需编译，真正做到了“改哪编译哪”。对于聊天系统这种迭代频繁的 UI 项目来说，这个开发体验差距是决定性的。

第二个价值在生产构建上。Vite 底层用 Rollup，代码分割和 Tree-Shaking 能力很强。Electron 渲染进程里的代码如果是一个巨大的单文件，加载慢不说，内存也得不到释放。Vite 默认会按动态 import 自动分包，比如聊天界面、通讯录界面、设置界面这些大模块可以被拆开，按需加载，白屏和卡顿都会明显改善。

第三个价值是插件生态。我现在已经离不开@vitejs/plugin-vue或@vitejs/plugin-react这套官方插件了，它们解决了 JSX/TSX 编译、热更新边界、CSS 预处理等一堆细节。如果不用 Vite，这些都要手动配。

1.3 Electron 本体在这个项目里的不可替代项

有些同学会问，既然前端部分用 Vite，那纯前端做一个网页版聊天系统不行吗？我当时也想过，但后来列出了浏览器永远做不到的几件事：

系统托盘常驻：聊天工具的核心使用习惯就是“挂在托盘里”，浏览器标签页被误关太常见了
原生窗口控制：自定义边框、置顶、最小化到托盘，这些只有桌面端能做
本地文件交互：头像图片缓存、聊天记录备份、导出文件，浏览器受限很多
系统通知：Windows 上原生通知和网页 Notification 的体验差距还是挺明显的
独立进程隔离：聊天工具卡死不能影响用户其他工作，浏览器一个标签卡死可能整站遭殃

所以 Electron 不是“没有选择的选择”，而是这个产品形态真正的合理容器。Vite 负责把容器里的前端体验做到极致，两者各司其职。

2. 工程化搭建：把 Vite 和 Electron 拧成一股绳的完整方案

这个阶段是我感觉最容易劝退新手的环节。单纯跑一个 Vite 项目很容易，单独跑一个 Electron 官方示例也容易，但让两者在开发环境下无缝协作，需要理解它们各自的运行机制。

2.1 先看最终的工程目录结构

我先直接放出我用下来的目录结构，这是一套经历过实战考验的组织方式。

electron-wechat/ ├── electron/ │ ├── main.ts # 主进程入口 │ ├── preload.ts # 预加载脚本 │ ├── tray.ts # 托盘逻辑 │ └── window.ts # 窗口管理 ├── src/ │ ├── main.ts # 渲染进程入口 │ ├── App.vue │ ├── components/ # 聊天界面组件 │ ├── stores/ # zustand/pinia 状态 │ ├── assets/ # 静态资源 │ └── styles/ ├── index.html ├── vite.config.ts ├── electron-builder.yml ├── package.json └── tsconfig.json

关键点在于：electron/目录放主进程和预加载脚本，src/目录放渲染进程代码。两者有着完全不同的运行环境，但共用同一个package.json。主进程跑在 Node.js 环境，渲染进程跑在 Chromium 环境，通过contextBridge搭建安全的通信桥梁。

2.2 开发模式的核心：Vite Dev Server 与 Electron 的启动时序

开发模式的理想状态是：启动一条命令，Vite 服务器先起来，Electron 再带着界面连上去，后续的代码变更全部走 HMR（热更新）。这里有个经典的时序问题：electron .启动太快，Vite 服务器还没 ready，窗口打开之后就是一片白屏。

我的解决方案是依赖两个工具：concurrently和wait-on。先说运行脚本：

{ "scripts": { "dev": "concurrently -k \"vite\" \"wait-on tcp:5173 && cross-env NODE_ENV=development electron .\"", "build": "vite build && tsc -p electron/tsconfig.json", "start": "electron ." } }

启动流程是这样的：concurrently并行跑 Vite 开发服务器和 Electron 启动命令。Electron 那条命令前面挂着wait-on tcp:5173，意思是只有探测到 5173 端口可以访问了，才真正执行electron .。这样 Vite 服务器一定是先就绪的，Electron 窗口一打开就能加载到页面。

主进程这边的加载逻辑也要区分开发和生产：

import { app, BrowserWindow } from 'electron'; import path from 'path'; const isDev = process.env.NODE_ENV === 'development'; function createMainWindow() { const win = new BrowserWindow({ width: 1200, height: 800, frame: false, webPreferences: { preload: path.join(__dirname, 'preload.js'), contextIsolation: true, nodeIntegration: false } }); if (isDev) { win.loadURL('http://localhost:5173'); } else { win.loadFile(path.join(__dirname, '../dist/index.html')); } } app.whenReady().then(createMainWindow);

这里有个容易栽的坑：生产环境的loadFile路径不是随便写的。如果vite build的输出目录是dist/，而主进程编译后的文件在electron/dist/下，就需要用path.join(__dirname, '../dist/index.html')精确指路。很多人的白屏问题就是路径算错了。

2.3 安全模型：contextIsolation 与 preload 的设计

Electron 从 12 版本起默认开启contextIsolation，这意味着渲染进程里不能直接用 Node.js 的require或process对象。这个设计看着限制很大，实际上是安全底线：聊天工具要加载用户消息、链接、头像，这些内容如果拥有 Node 权限，等于把电脑敞开给任何恶意脚本。

正确姿势是使用 preload 脚本做桥接，配合contextBridge暴露白名单 API：

import { contextBridge, ipcRenderer } from 'electron'; contextBridge.exposeInMainWorld('chatAPI', { sendMessage: (content: string) => ipcRenderer.invoke('chat:send', content), onMessageReceived: (callback: (msg: Message) => void) => { const handler = (_event: unknown, msg: Message) => callback(msg); ipcRenderer.on('chat:receive', handler); return () => ipcRenderer.removeListener('chat:receive', handler); }, minimizeWindow: () => ipcRenderer.send('window:minimize'), maximizeWindow: () => ipcRenderer.send('window:maximize'), closeWindow: () => ipcRenderer.send('window:close') });

渲染进程里通过window.chatAPI.sendMessage('你好')这种方式调用，永远接触不到底层 Node 能力。这也是我做这个项目时特别想强调的部分：不要在渲染进程里开 nodeIntegration，这个习惯一旦养成就很难改，而且会埋雷。

2.4 生产构建的两段式流程

生产构建需要认识到：这个项目里有两种代码要分别打包。

渲染进程代码（Vue/React 组件、业务逻辑、样式）通过vite build打包成纯静态资源
主进程和 preload 的 TypeScript 代码通过tsc编译成 CommonJS

我最初把两边混合在一起处理，结果主进程代码被 Rollup 处理后丢失了 Node 依赖的上下文，各种报错。后来拆开就非常清爽：主进程代码保持 CommonJS 格式，渲染进程代码走 Vite 的 ESM 分割。生产环境的启动路径已经在 2.2 写过了，不再赘述。

3. 仿微信桌面端的窗口与界面架构

做仿微信这个项目，UI 层是最感性、最出效果的部分，但也最容易只做表面功夫。我先把窗口层谈透，再谈界面细节。

3.1 无边框窗口与自定义标题栏

微信电脑版没有系统标题栏，是纯自定义的。Electron 里对应设置就是frame: false，把系统原生边框去掉，然后用 HTML/CSS 自己画标题栏。

我的标题栏结构长这样：

<div class="titlebar"> <div class="titlebar__left"> <img src="./logo.svg" class="logo" alt="logo" /> <span class="app-title">WeChat Desktop</span> </div> <div class="titlebar__right"> <button @click="minimize">--</button> <button @click="toggleMaximize">[]</button> <button @click="close">x</button> </div> </div>

关键 CSS 是-webkit-app-region，这套属性决定了哪些区域可以被鼠标拖拽移动窗口：

.titlebar { height: 48px; display: flex; justify-content: space-between; align-items: center; background: #f5f5f5; -webkit-app-region: drag; /* 整个标题栏都是拖拽区 */ } .titlebar button { -webkit-app-region: no-drag; /* 按钮区域必须排除拖拽 */ }

我的实测经验是：务必把可交互元素都标上no-drag。否则你点击按钮时会发现鼠标事件像被一层透明罩盖住，按钮按下去没反应，这个坑太常见了。

3.2 左侧导航栏的像素级还原思路

微信左侧栏的核心特征：固定宽度约 60-70px，深色背景，一列图标的导航列表，选中态是高亮色块，旁边的红点角标表示未读消息。

这个 UI 本身不难，难在细节一致性。我总结了三件套：

统一用 SVG 图标，线条粗细保持 1.5px 一致
选中态的过渡动画控制在 150ms，快了生硬、慢了拖沓
红点用绝对定位的伪元素实现，不额外增加 DOM 节点

红点代码可以放出来参考：

<div class="nav-item"> <svg><!-- 图标 --></svg> <span class="badge" v-if="unreadCount > 0">{{ unreadCount > 99 ? '99+' : unreadCount }}</span> </div>

.nav-item { position: relative; } .badge { position: absolute; top: 2px; right: 2px; min-width: 16px; height: 16px; background: #fa5151; border-radius: 8px; color: #fff; font-size: 11px; line-height: 16px; text-align: center; padding: 0 4px; }

3.3 置顶、缩放与多窗口的 IPC 控制

自定义标题栏意味着原生窗口控制钮没了，这些操作必须转发到主进程。我用ipcRenderer.send发事件，主进程用BrowserWindow实例响应。

ipcMain.on('window:minimize', (event) => { BrowserWindow.fromWebContents(event.sender)?.minimize(); }); ipcMain.on('window:maximize', (event) => { const win = BrowserWindow.fromWebContents(event.sender); if (!win) return; win.isMaximized() ? win.unmaximize() : win.maximize(); }); ipcMain.on('window:close', (event) => { BrowserWindow.fromWebContents(event.sender)?.hide(); });

注意这里最后一项：close按钮不是真正退出应用，而是隐藏窗口到托盘。这是模仿微信的基础行为——用户点关闭，应用继续在托盘里待命，消息来了照样弹通知。这是聊天工具最核心的交互习惯之一。

3.4 系统托盘与常驻逻辑

托盘在 Electron 里实现非常成熟，核心就是用Tray和Menu两个类。我的实现是：

import { Tray, Menu, app } from 'electron'; let tray: Tray | null = null; export function createTray() { tray = new Tray(path.join(__dirname, 'assets/tray-icon.png')); const contextMenu = Menu.buildFromTemplate([ { label: '显示主界面', click: () => mainWindow.show() }, { type: 'separator' }, { label: '退出', click: () => app.quit() } ]); tray.setToolTip('WeChat Desktop'); tray.setContextMenu(contextMenu); tray.on('click', () => { mainWindow.isVisible() ? mainWindow.hide() : mainWindow.show(); }); }

需要在app.whenReady()之后调用createTray()。另外 **macOS 的托盘图标需要处理空白边距，**一个常见的坑是图标过小或像素不清晰，用@2x分辨率的图片更稳妥。

4. 聊天核心数据流：消息、会话与多窗口弹窗

界面做得再像，没有一套硬核的数据流设计，项目也只是皮囊。这一章是全文的灵魂，我会把消息模型、状态管理、窗口间通信、虚拟滚动全部交代清楚。

4.1 先把消息模型定义清楚

聊天系统最重要的就是消息数据结构。我的 TypeScript 定义如下：

interface User { id: string; nickname: string; avatar: string; signature?: string; } interface Message { id: string; conversationId: string; senderId: string; content: string; type: 'text' | 'image' | 'file' | 'system'; timestamp: number; status: 'sending' | 'sent' | 'delivered' | 'read'; } interface Conversation { id: string; peer: User; messages: Message[]; unreadCount: number; lastMessage?: Message; pinned?: boolean; draft?: string; }

单聊、群聊都统一用Conversation承载，消息通过conversationId归属。字段设计上我特别保留了status，因为聊天软件里消息状态提示是刚需，虽然我这个 demo 里只是 mock，但字段先设计到位后面接真实后端时不用动结构。

4.2 状态管理与持久化的轻量方案

聊天软件的状态量非常大：会话列表、当前会话、未读数、窗口状态、搜索关键词……如果用 React 的useState手动管理，很快就会一团乱麻。我用的是 Zustand，比 Redux 轻太多，写起来既简单又能满足复杂状态需求。

import { create } from 'zustand'; interface ChatState { conversations: Conversation[]; activeConversationId: string | null; sendMessage: (conversationId: string, content: string) => void; receiveMessage: (message: Message) => void; markAsRead: (conversationId: string) => void; } export const useChatStore = create<ChatState>((set, get) => ({ conversations: seedConversations(), activeConversationId: null, sendMessage: (conversationId, content) => { // 构造消息并追加到对应会话 }, receiveMessage: (message) => { // 根据 message.conversationId 找到会话并追加 }, markAsRead: (conversationId) => { // 未读清零 } }));

Zustand 的优势在于：不需要 Provider 包裹、可以在任何组件或普通函数里调用、状态变化只触发真正订阅的组件重渲染。聊天列表每秒都可能更新未读数，用 Zustand 的selector做精准订阅，性能表现非常好。

持久化这块要注意：localStorage在 Electron 渲染进程里是可用的，但存敏感数据时我强烈建议走主进程写文件。原因有两个：一是 localStorage 在清除浏览器数据时会丢；二是contextIsolation开启后，渲染进程里的localStorage其实受 Chromium 存储分区管理，用户体验不可控。我的做法是 IPC 调用主进程，把聊天记录 JSON 写入用户数据目录下的chat_history.json。

4.3 聊天窗口的模式选择：单页切换还是独立窗口

这里我要多说一点。很多仿微信的教程都是路由切换：点击左侧会话，右侧聊天面板换成对应内容。这个方案简单，但和微信电脑版的真实体验有差距。微信电脑版里，双击某个会话可以弹出一个独立聊天窗。

我在项目里做了一个混合方案：默认主窗口右侧面板是聊天区域，但双击会话列表的外层区域会打开一个独立的BrowserWindow聊天窗。这个独立窗口有独立的会话上下文，通过 URL query 传递conversationId：

function openChatWindow(conversationId: string) { const chatWindow = new BrowserWindow({ width: 400, height: 600, frame: false, webPreferences: { preload: path.join(__dirname, 'preload.js'), contextIsolation: true } }); const url = isDev ? `http://localhost:5173/#/chat/${conversationId}` : `${path.join(__dirname, '../dist/index.html')}#/chat/${conversationId}`; chatWindow.loadURL(url); }

主窗口和独立聊天窗之间如何同步消息状态？这里有个经验总结：多窗口场景下，消息更新应该走“广播”而不是父子查询。也就是说，当某个窗口发出消息后，主进程把新消息广播给所有相关窗口。每层窗口自己维护 UI 状态，各自更新。

function broadcastMessage(message: Message) { const windows = BrowserWindow.getAllWindows(); windows.forEach((win) => { win.webContents.send('chat:receive', message); }); }

这个方案最接近真实 IM 客户端的设计，也避免了一个窗口修改另一个窗口状态的耦合问题。

4.4 从发送到回执：一条消息的完整生命周期

完整链路如下：

用户在聊天输入框按下回车
渲染进程调用window.chatAPI.sendMessage(conversationId, content)
Preload 通过ipcRenderer.invoke把请求转发给主进程
主进程在ipcMain.handle里构造 Message 对象，存到本地，然后广播给所有窗口
主进程模拟对方回复：延迟 1-2 秒后再广播一条新的Message
渲染进程监听chat:receive，更新 Zustand store，界面刷新

这里ipcRenderer.invoke和ipcRenderer.send的区别要澄清一下：invoke是异步请求/响应模式，渲染进程能拿到主进程的返回值；send是单向通知，不关心返回值。发送消息需要拿到构造好的消息 ID，所以用invoke；窗口控制之类的不需要返回值，用send就够了。

主进程的核心代码：

ipcMain.handle('chat:send', async (event, payload) => { const { conversationId, content } = payload; const message: Message = { id: crypto.randomUUID(), conversationId, senderId: 'me', content, type: 'text', timestamp: Date.now(), status: 'sent' }; saveMessageToDisk(message); broadcastMessage(message); // mock 回复 setTimeout(() => { const reply: Message = { id: crypto.randomUUID(), conversationId, senderId: 'peer', content: '收到你的消息啦，这里是自动回复', type: 'text', timestamp: Date.now(), status: 'sent' }; saveMessageToDisk(reply); broadcastMessage(reply); }, 1200); return message; });

4.5 聊天列表的虚拟滚动：不能省

聊天记录会越来越多，如果直接把数组全量渲染成 DOM，几千条消息之后界面就会开始卡顿。虚拟滚动是必须的。

我的精简实现思路：固定每一项高度（比如文本消息 64px，图片消息自适应一种固定宽高），然后用一个可滚动容器，只渲染视口可见范围内的消息项。核心代码：

const scrollRef = ref<HTMLDivElement>(); const visibleRange = ref({ start: 0, end: 20 }); const ITEM_HEIGHT = 64; const buffer = 5; // 上下各多渲染几条作为缓冲 function onScroll() { const scrollTop = scrollRef.value?.scrollTop ?? 0; const viewportHeight = scrollRef.value?.clientHeight ?? 0; const start = Math.max(0, Math.floor(scrollTop / ITEM_HEIGHT) - buffer); const end = Math.min( messages.value.length, Math.ceil((scrollTop + viewportHeight) / ITEM_HEIGHT) + buffer ); visibleRange.value = { start, end }; }

当会话有大量历史消息时，用虚拟滚动可以把 DOM 节点数量从几千降到几十个，滚动流畅度是质的区别。我实测过：3000 条消息全量渲染需要几百毫秒，虚拟滚动后滚动帧率保持 60FPS 没有压力。

5. 性能优化与打包上线的关键细节

做完功能只是开始，Electron 项目的真正分水岭在性能和打包。

5.1 图片资源的加载策略

聊天应用里最耗费资源的是头像和聊天图片。我总结出了一套分级策略：

小图标（16px、24px 的导航图标）：直接用 SVG，打包进 bundle，避免任何网络加载
用户头像：默认头像用本地 base64 或 asset 文件，用户后台上传的头像走 HTTP 缓存
聊天图片：用懒加载 + 按需解码，loading="lazy"配合 IntersectionObserver

还有一个容易忽略的点：Electron 里加载 HTTP 资源受到 Web Security 限制。如果页面是file://协议的本地文件，直接请求http://接口会被 CORS 拦截。我当时在本地走http://localhost:5173没问题，打包后变成file://协议就踩了 CORS 的坑。解决方案有两层：主进程用session.defaultSession.webRequest.onBeforeSendHeaders配置跨域头，或者后端接口配置正确的 CORS 允许来源。

5.2 electron-builder 配置与打包体积控制

我用的是 electron-builder，配置写在electron-builder.yml：

appId: com.example.wechat-desktop productName: WeChatDesktop directories: output: release files: - dist/** - electron/** - package.json win: target: - nsis mac: target: - dmg nsis: oneClick: false allowToChangeInstallationDirectory: true createDesktopShortcut: true createStartMenuShortcut: true

这里有三个容易踩的坑：

files配置决定哪些文件进安装包，如果漏了dist/**，打包后启动就是白屏
Electron 版本会带来体积差异，每升一个 major 版本，安装包体积可能增加 10-20MB，建议锁定版本而不是一直追新
图标必须是.ico格式（Windows）和.icns格式（macOS），普通 PNG 转换不规范会导致打包报错

实际打完包的体积：基础 Electron 约 60MB，加上应用代码和资源，最后大约 80MB。相比 Tauri 确实大，但换来的是跨平台一致性和庞大的生态支持，这个交易我是接受的。

5.3 白屏问题的排查路径

白屏是 Electron 新手最容易遇到的问题，我梳理一下自己的排查顺序：

确认加载方式：开发环境用loadURL时检查端口是否被占用，生产环境用loadFile时检查路径是否正确
看 DevTools Console：主进程报错会在终端显示，渲染进程报错需要手动打开 DevTools 查看
检查index.html里的资源路径：Vite 默认base: '/'，如果打包后以file://协议加载，绝对路径会失效，需要在vite.config.ts里设置base: './'

export default defineConfig({ base: './', // 关键！否则 file:// 协议下资源加载失败 plugins: [vue()], build: { outDir: 'dist', assetsDir: 'assets' } });

初始化白屏还有一种可能：渲染进程代码里某个await一直 pending，比如初始化时调用了chatAPI.getHistory()但主进程没有对应 handler。排查方法是在渲染进程代码里加日志或setTimeout定位卡住的位置。

5.4 长时间驻留的内存问题与排查

托盘常驻应用的特性就是“长期不退出”，这会让内存问题变得特别敏感。我遇到过聊天窗口开久了内存缓慢上涨的情况。

需要检查的几个方面：

是否每个消息都触发了整个会话列表的重渲染（用 Zustand selector 控制到消息项粒度）
是否有 EventListener 没移除，尤其是每开一个聊天窗口就挂一个onMessageReceived监听器，关闭窗口时忘了清理
远程图片是否被加入内存缓存，长时间不释放

调试工具用的是 Electron 内置的webContents.openDevTools()里的 Performance 面板，配合 Memory 快照对比，能很快定位到泄漏点。我的经验是：**90% 的内存问题出在“监听器重复挂载”和“大列表全量渲染”**，把这两个治理好，内存就基本稳了。

6. 实操中的遗留问题与最终体会

项目做到最后，总有几个问题没能彻底完美解决，这里也坦诚分享一下。

第一是视频通话功能没有做。桌面 IM 客户端的视频通话涉及摄像头采集、音视频编码、P2P 连接，这不是一个人短期内能打磨完的，我选择了先把基础聊天体验做透，这个取舍我认为是对的。

第二是消息加密与本地数据库方案。目前用 JSON 文件存聊天记录，只适合 demo 和小型内部工具，如果要做得更正式，建议引入 SQLite 或 LevelDB，配合主进程的加密模块做落地。这块涉及better-sqlite3的编译，以及和 electron-rebuild 的配合，步骤还算丰富，但需要额外预算。

第三是自定义标题栏在 macOS 上的细节。macOS 的窗口红绿灯按钮位置和交互习惯和 Windows 不一样，微信电脑版在两种系统上的标题栏布局也不同。我这个项目的标题栏更贴近 Windows 风格，如果真要考虑 mac 用户，窗口控制按钮的位置要单独适配。

做完整个项目，我最大的体会是：Electron 开发的最大瓶颈不是框架本身，而是你对“桌面端产品完整性”的理解。会不会做托盘常驻、会不会处理多窗口通信、会不会做消息持久化、会不会控制内存增长——这些才是真正拉开差距的地方。Vite 解决了开发体验和构建质量，Electron 提供了容器和系统能力，两者结合的工程化沉淀下来，能非常直接地复用到其他任何 Electron 项目里。

最后再分享一个我后来才养成的习惯：每个 Electron 项目里都用electron-log记录主进程日志，开发环境和生产环境都留出口，用户现场出的问题能靠着日志快速定位，省下的排查时间远超写日志的成本。这个建议我强烈安利给所有准备做 Electron 项目的朋友。