Discord 为何弃用 Electron 转向 Rust？

在一张 Windows 11 任务管理器截图中，名为“Discord Phoenix”的进程占用内存 290.2MB，而截图时该客户端同时登录了两个账户。旧版 Electron 客户端在空闲状态下通常占用 1GB 至 2GB，极端情况下可能达到 4GB。这里比较的是运行内存，不是安装包体积。

Discord 此次迁移并非简单地将 Electron 换成另一种框架，而是同时更换了实现语言和界面渲染栈。新的桌面客户端由 Rust 重写，界面层采用 Zed 编辑器团队开发的 GPUI，通过 GPU 加速的原生 Rust UI 取代 Chromium 和 WebView；只有 YouTube、Activities 等嵌入式内容仍会调用系统 WebView。Rust 提供新的客户端实现基础，GPUI 则直接改变主界面的渲染方式，这两者承担的是不同任务。

“4GB 降至 290MB”并不是严格意义上的同条件对照。新截图记录的是一个同时登录两个账户的特定进程，旧版数据则覆盖空闲和极端使用状态，不能把两者的差值直接视为所有用户都能获得的固定降幅。不同设备、系统版本、服务器数量和运行时长都会影响最终结果，因此 290.2MB 更适合作为一个积极信号，而不是新的通用基准。

同样不能从这一个内存数字外推安装包大小、启动速度、CPU 与 GPU 占用或耗电表现。内存、磁盘、计算和渲染属于不同维度；一个原生客户端即使显著降低了内存占用，也不代表所有性能指标都会同步改善。验证这次重写是否成功，仍然需要实际测试版、稳定版以及不同工作负载下的连续数据。

旧版 Discord 的资源压力首先来自 Electron 的基础架构。每个 Electron 应用都会携带一份完整的 Chromium 浏览器内核，而不是像 WebView 那样使用系统提供的渲染引擎。公开资料还指出，Discord 一度被视为优化较差的 Electron 应用之一，在打开服务器或长时间使用后，内存占用会持续攀升。

这意味着旧客户端面对的并非单个页面或某次更新造成的孤立泄漏，而是“浏览器运行时本身的基础成本”与“Discord 长时间运行后的业务增长”叠加在一起。单纯压缩几张图片、减少未使用界面或调整某个功能模块，很难从根本上改变这条资源曲线。

Discord 此前也进行过针对性治理。公司曾测试在内存占用超过 4GB 时自动重启客户端，并表示正常使用的内存占用应低于 1GB；同时还定位并修复了多个内存泄漏场景，使高负载下的 P95 内存占用下降约 5%。P95 是将用户内存数据排序后处于第 95 百分位的数值，即排除最极端的约 5% 情况后的高负载水平。

这些措施能够缓解问题，但自动重启本质上仍是事故保护，而不是根治；约 5% 的 P95 降幅也说明，泄漏治理无法抵消 Electron 基础架构带来的整体成本。Discord 最终选择重写客户端，意味着它希望同时处理运行时基础开销和长期使用中的增长问题，而不只是继续围绕泄漏点打补丁。

新客户端的核心变化，是把主界面从 Chromium 渲染链路中移出。GPUI 是一款由 Zed 编辑器团队开发的 GPU 加速原生 UI 框架，不依赖 WebView 或 Chromium 绘制 Discord 的主要界面。维什涅夫斯基还把“让整个客户端都跑在 Rust 上”描述为长期目标，这表明移动端迁移也在同一技术路线之内。

因此，把这次变化概括成“Rust 天然更省内存”并不准确。Rust 不会自动消除业务代码中的引用泄漏、缓存膨胀或后台任务积压；主界面资源占用的变化直接来自原生 UI 与 GPUI。Rust 还用于为桌面端和移动端建立统一的实现层，并支持两端共享应用代码。

Tauri 提供了另一种常见路线。它是跨平台 GUI 框架，前端使用 Web 技术，后端可以使用 Rust；渲染时调用操作系统提供的 WebView，因此能够避免随应用打包完整 Chromium。 但 Discord 最终没有选择 Tauri，而是采用原生 Rust UI 路线，只在确实需要网页内容时保留 WebView。

这也说明，Electron、Rust 和 Tauri 并不是可以互换的技术标签。语言决定代码如何实现，GUI 框架决定界面如何绘制，WebView 嵌入策略又决定哪些内容仍然运行在浏览器引擎中。Discord 此次同时调整了这些环节，其目的不只是降低内存，还要为后续桌面端和移动端共享代码建立更一致的基础。

OpenCode 从 Tauri 切回 Electron 的案例可以作为反向参照。该团队给出的理由包括：macOS 和 Linux 上的 WebKit 性能不及 Chromium，不同平台之间存在样式差异；打包的 CLI 影响启动速度，并在 Windows 上出现偶发失败；采用 Electron 后，可以利用其内置的 Node 进程运行服务器代码，从而减少一层运行时依赖。

这并不能证明 Electron 普遍优于 Tauri，也不能证明原生 UI 一定是所有项目的最佳选择。桌面框架的取舍最终取决于业务负载：UI 密度、跨平台一致性、启动要求、运行时依赖和嵌入式网页需求，都可能改变结论。Discord 与 OpenCode 选择了相反方向，也说明“Rust”或“Electron”本身都不是答案。

移动端的迁移范围比桌面端更广。iOS 和 Android 客户端计划逐步使用 Rust 替换当前的 React Native，但会继续保留各自的原生 UI，并通过 Rust 与桌面端共享应用代码。这里的重点是替换客户端的实现层，而不是把移动界面也改成桌面 GPUI 风格的 Rust 绘制界面。

对用户而言，目前可以确认的变化包括：主应用将原生化，外观和操作据称会与现版保持一致，新客户端支持多账户；YouTube、Activities 等嵌入内容则继续使用系统 WebView。现有资料不足以确认所有插件、扩展、数据迁移和兼容场景都已经得到保证，因此“核心体验一致”不能扩大解释为“所有生态毫无变化”。

发布节奏也尚未完全确定。维什涅夫斯基表示，新客户端很快将进入面向用户的测试阶段，但没有给出正式发布时间，Discord 官方也尚未发布独立公告。现阶段更适合把它理解为迁移验证期，而不是已经全面上线：测试重点将包括资源占用、稳定性、兼容性，以及原生 UI 在不同系统上的实际表现。

对普通用户来说，下一步不是根据 290.2MB 立即判断新版一定更好，而是等待测试版开放后，在相同设备上分别记录旧版与新版的内存变化。测试至少应覆盖空闲、多账户、多服务器和长时间运行等场景，并关注内存峰值与持续增长趋势，而不只是截取一个时刻的任务管理器数值。

对开发者来说，下一步也不应是先把 Electron 项目机械地翻译成 Rust，而应拿一个代表性主界面和一个真实嵌入式网页做原型，依次回答四个问题：主界面需要浏览器渲染还是原生绘制，是否依赖外部网页内容，各平台的渲染与交互能否保持一致，以及如何在长时间运行中监控泄漏和资源增长。框架选择最终应由这些约束决定，而不是由某一种语言的热度决定。