Deno Desktop：2.9 新版，把 Web 应用一键打包成桌面二进制
Deno
桌面应用
开源
工具
2026/9/29
·
阅读时间: 大约 8 分钟
Deno Desktop：2.9 新版，把 Web 应用一键打包成桌面二进制
桌面应用打包工具这两年突然热闹了起来：Electron 太胖、Tauri 要写 Rust、Electrobun 锁 Bun。Deno 2.9.0 正式内置了 deno desktop 命令——把从单个 TypeScript 文件到整个 Next.js 应用的 Deno 项目，编译成”代码 + Deno 运行时 + 网页渲染引擎”打包在一起的独立二进制。本文基于官方文档（docs.deno.com/runtime/desktop）实读，重点看它和 Electron/Tauri 的官方对比表。
一、它的几个关键取舍
官方文档把设计取向讲得非常直白：
- 小体积默认 + 可换内核：默认用操作系统自带 WebView（macOS WKWebView / Windows WebView2 / Linux WebKitGTK），体积小；需要三端渲染像素一致时，显式 opt-in 打包 CEF（Chromium Embedded Framework）；
- 完整 npm 生态：通过 Deno 的 Node 兼容层保留 npm 包，不用像 Tauri 那样前后端分家；
- 框架自动识别：Next.js / Astro / Fresh / Remix / Nuxt / SvelteKit / SolidStart / TanStack Start / Vite SSR 项目指过去就跑，生产模式起 server、开发模式带 HMR；
- 进程内通道替代 IPC：后端与 UI 通信走 in-process channels，不走 socket 跨进程往返；
- 交叉编译：一台机器构建 macOS/Windows/Linux 三端产物，后端按需下载；
- 内置 bsdiff 增量更新：发布一个
latest.json清单 + bsdiff 补丁包，运行时轮询、启动失败自动回滚。
二、官方对比表（2026-09 文档实读）
Deno 官方自己做了一张对比表，把自己和 Electron / Electrobun / Tauri / Dioxus 放在一起：
| 维度 | Electron | Electrobun | Tauri | Dioxus | deno desktop |
|---|---|---|---|---|---|
| 语言 | JS/TS (Node) | JS/TS (Bun) | Rust + Web | Rust | JS/TS (Deno) |
| Web 引擎 | 打包 Chromium | 系统 WebView | 系统 WebView | 系统 WebView | 打包 CEF 或系统 WebView |
| 渲染一致 | 是 | 否 | 否 | 否 | 是（CEF） |
| 后端↔UI | IPC | IPC | IPC | Native Rust | 进程内通道 |
| 包体积 | ~100MB+ | ~61MB | ~2–10MB | ~5MB | ~40MB / ~150MB (CEF) |
| npm 兼容 | 是 | 是 | 否 | 否 | 是 |
| 框架自动识别 | 否 | 否 | 否 | 否 | 是 |
| HMR | 否 | 是 | 是 | 是 | 是 |
| 内置更新 | 全量二进制 | bsdiff | 插件 | 无 | bsdiff |
| 交叉编译 | electron-builder | 否（需目标机） | 否 | 否 | 是（—target） |
三、口径与局限（重点）
- “~40MB”是系统 WebView 模式，“~150MB”才是 CEF 模式。 别被”小体积”宣传误导：默认 WebView 模式确实 ~40MB，但和 Tauri 的 2–10MB 比仍然胖——因为 Deno 运行时本身不小；要渲染一致就得吃 150MB。这是它在体积上的两头不靠。
- 系统 WebView 的渲染一致性老问题。 Koala 点评一针见血：复用系统 WebView 意味着 macOS/Windows/Linux 三端用不同内核，CSS/Web API 表现不一致——这是所有原生 WebView 方案（Tauri/Electrobun）绕不开的坑。Deno 给出的答案是”切 CEF”，但切了就回到 150MB 体积。
- “进程内通道”听着美好，但进程模型变了。 文档自己承认 WebView 后端是 process group、CEF 是 multi-thread——和 Electron 的多进程沙箱模型不同，崩溃隔离性要重新评估。
- 没有移动端。 对比表里 iOS/Android 一行：Electron/Electrobun/deno desktop 都是”No”，Tauri/Dioxus 才支持。想做跨端 App 的话它目前只覆盖桌面。
- 刚发布。 Deno 2.9 是 2026 年的新版本，
deno desktop属于早期 API，文档里大量章节（Bindings、Menus、Tray、Auto-update）还在打磨，生产选型要预留 API 变动空间。 - “框架自动识别”不等于零配置。 文档承认”Most frameworks need no special adapter”——“most”这个词留了余地，具体到每个框架仍要看 Frameworks 章节。
四、客观评价
优势：
- JS/TS 全栈一体，npm 生态完整，无需 Rust；
- 框架自动识别 + HMR，从 Web 项目迁桌面的迁移成本最低；
- 一台机器交叉编译三端，CI 友好；
- bsdiff 增量更新 + 失败回滚是开箱即用的工程能力。
局限：
- 体积在 Tauri（10MB）和 Electron（100MB+）之间，两头都不极端；
- 系统 WebView 一致性问题没回避；
- 无移动端；
- 早期版本，API 与工具链仍在演进。
五、谁该关注
已经在 Deno 生态里做全栈 Web 应用、想顺手出个桌面版的团队——deno desktop . 几乎零成本。追求极致小体积（10MB 以内）的，Tauri 仍是首选；要像素级三端一致且不在意体积，Electron 成熟度更高。它最现实的位置是：Deno 用户的桌面出口，而不是 Electron 的通用替代品。