当一个团队发布用 JavaScript 或 TypeScript 构建的桌面应用时，它交付给用户的往往不只是用户界面。发行包里可能还包含业务规则、许可证校验逻辑、配置信息、离线工作流以及各种集成代码。
在典型的 Web 应用中，这些逻辑的大部分都可以保留在服务端。但在桌面应用里，至少有一部分逻辑会最终落到用户的机器上，在那里它们可以被查看、被修补，也可以被重新打包。
在这篇文章中，我想聊一聊为什么这个问题很难回避，"源码保护"在实践中究竟指的是什么，以及 Electron、Tauri 和 MōBrowser 今天分别是如何应对它的。
为什么源码保护很重要
对商业桌面软件来说，担心的问题通常不仅仅是"有人出于好奇翻了几眼源码"。团队往往同时担心好几件事：
- 专有业务逻辑的暴露
- 许可证与校验流程被分析
- 应用行为被篡改
- 被修改后重新打包发布
- 配置信息和集成细节被提取
JavaScript 让这种担忧更加突出，因为发布出去的代码通常比原生机器码更接近原始源码。这并不意味着原生应用就不会被逆向，而是说，如果目标是隐藏实现细节，JavaScript 桌面应用往往从一个更不利的起点开始。
在比较各个框架之前，先区分一下"源码保护"这个短语下经常被混为一谈的几个完全不同的概念，会更有帮助。
"源码保护"到底指什么
在实践中，团队通常需要以下五件事的某种组合：
- 打包（Packaging） — 把应用文件放进一个 bundle 或归档中。
- 混淆（Obfuscation） — 让代码更难阅读。
- 转换（Transformation） — 使用字节码或加密类机制，让随意提取变得更麻烦。
- 完整性（Integrity） — 检测打包后的文件是否被修改过。
- 架构（Architecture） — 从根本上让最敏感的逻辑不暴露在 JavaScript 中。
这几个层次解决的是不同的问题。打包不等于保护，代码签名不等于加密，混淆不等于防篡改。一旦这些概念被搅在一起，团队往往会以为自己得到了比实际更强的防护。
为什么这件事很难
这个问题始终无法被彻底解决，背后有一个结构性的原因：应用必须运行在用户的机器上，运行时最终总得以某种可用的形式拿到代码或资源。足够执着的攻击者可以研究磁盘上的文件、对运行时进行插桩、检查内存，或者直接打补丁修改应用二进制。
这也是为什么，对大多数客户端 JavaScript 应用来说，追求"绝对保密"是一个错误的目标。一个更现实的目标是：提高检查和篡改的成本，减少容易攻击的路径，以及把最敏感的逻辑搬到暴露面更小的地方。
这同样也是为什么"混淆一下就行"很少是一个令人满意的答案。混淆能应对随意的翻查，但它并不改变代码最终仍要在本地执行这个事实。
Electron 中的源码保护
Electron 让这个问题很容易暴露出来，因为它的默认打包格式 ASAR 本质上就是为了打包而不是为了保密。这个归档格式是公开的，标准工具可以轻松解压它，解压后的 JavaScript 文件依然完全可读。
但这并不意味着 Electron 开发者没有可用的防御手段。在实践中，团队通常会叠加使用几种机制：
- ASAR 打包：将文件打包进
app.asar。 - V8 字节码：把部分 JavaScript 代码转成字节码，使其更难阅读。
- ASAR 完整性校验：在运行时检测打包归档是否被修改。
- 代码签名：让操作系统能够验证应用的来源。
这些机制都有帮助，但每一个解决的问题都比"源码保护"这个短语所暗示的要窄。
字节码是 Electron 常见工具链里最接近"代码隐藏"的东西。例如，electron-vite 可以在生产环境把 main 进程和 preload 脚本编译为 V8 字节码。但它自己的文档也很谨慎地说明了局限：这项能力覆盖不了所有场景、存在兼容性约束，且敏感字符串还需要额外的处理。
ASAR 完整性校验解决的是另一个问题。Electron 可以在运行时校验 app.asar 的完整性元数据，并在校验失败时终止应用。这对篡改检测有用，但并不会让代码变得不可读。
代码签名则又是另一码事。它帮助操作系统和用户确信分发出来的二进制确实来自预期的发布方。它不会隐藏 bundle 里的 JavaScript 源码。
所以今天 Electron 的实际答案是"分层加固"，而不是某种单一的内置保护模型。这能抬高攻击门槛，尤其是对 main 和 preload 部分，但它并不会把发布出去的 JavaScript 变成一个被密封的产物。
Tauri 中的源码保护
Tauri 从另一个方向切入这个问题。它不再打包一个内置的 Chromium 运行时，而是依赖系统自带的 WebView，并把它的安全模型聚焦在前端与特权核心之间的信任边界上。
这套安全模型包含几个重要部分：
- 前端运行在 WebView 中，被视为信任等级较低的一侧
- 对特权命令的访问通过 capabilities（能力）来控制
- 通信经由基于消息传递的 IPC 层完成
- Content Security Policy（CSP）可以减少脚本注入和非预期资源加载带来的影响
这是一种有意义的安全设计，但它回答的是稍有不同的问题。Tauri 官方的安全指引主要是关于"限制前端被允许做什么"以及"把特权逻辑保留在 Rust 一侧"，它并没有把前端源码的隐藏作为一个内置的保护特性来呈现。
这个区别很重要。如果你的敏感逻辑可以从 Web 层迁移到 Rust 命令里，Tauri 给了你一个更清晰的边界。但如果你的产品仍然以 Web 资源的形式发布大量有价值的前端逻辑，那些前端代码依旧是客户端产物——不能仅仅因为整个框架有一个强有力的安全叙事，就把它们当作"秘密"来对待。
换句话说，Tauri 最强的优势在于架构层面。当团队能够减少前端中高价值逻辑的比例时，它的效果最好。
MōBrowser 中的源码保护
MōBrowser 则更直接地在打包和运行时层面处理这个问题。它提供了一个内置机制：在构建阶段对应用源码和打包的资源进行加密，把它们打进一个受保护的二进制格式，并在运行时按需解密。
这些受保护的文件会与生成它们的那次具体构建绑定，目的是让"直接提取、复用、重新打包"这种路径变得更难。
现实中的区别在于：MōBrowser 把源码保护作为框架的内置能力，而不是要求应用团队自己用一堆独立工具拼出来。对于希望保持 JavaScript 或 TypeScript 为主的技术栈、同时又想抬高代码提取成本的团队来说，这比 Electron 开箱即用的默认值要强一些。
MōBrowser 还给团队提供了另一种架构选项。如果某些逻辑过于敏感，或者过于依赖特定平台，不适合留在 TypeScript 里，应用可以通过一个原生 C++ 模块来扩展——该模块以编译后的形态构建并发布。这并不会消除框架保护机制的必要性，但它让团队能够把选定的逻辑放到原生二进制边界的背后，而不必一股脑把所有东西都以 JavaScript 的形态发布出去。
同时，MōBrowser 也为"必须以文件形式保持可访问"的资产留了一个明确的"安全出口"：它的 resources 目录是未经加密就发布出去的。这对某些场景很有用，也是一个提醒——不要把密钥或许可证逻辑放到这里。
| 能力 | Electron | Tauri | MōBrowser |
|---|---|---|---|
| 打包 | 单一归档（ASAR） | 不做打包（前端侧） | 加密二进制文件 |
| 源码保护 | 无 | 无（前端侧） | 有（构建期加密） |
| 解压后代码可读性 | 完全可读 | 完全可读（前端侧） | 加密且受保护 |
| 抵御逆向工程能力 | 低 | 前端低、后端较高 | 前后端均较高 |
| 防篡改 | 有限 | 前端无保护 | 可防止直接修改 |
| 性能开销 | 无 | 无 | 极小 |
开发者应当关注的要点
框架的选择很重要，但架构更重要。有几条原则对上述三种方案都适用。
不要把前端 JavaScript 当作放秘密的安全地方。 API Key、许可判断、防篡改规则以及其他高价值校验，只要有可能，就应该留在后端，或者移到一个暴露面更小的边界中。
不要把打包和保护混为一谈。 一个单一归档也许让部署更干净，但它并不会自动让其中的内容变成秘密。
不要把签名和保密混为一谈。 签名依然重要，它关乎信任、分发和完整性，但它并不会让被提取出来的代码变得不可读。
用好框架真正的强项。 在 Electron 里，这通常意味着叠加多种加固手段，而不是只靠 ASAR。在 Tauri 里，这意味着认真对待信任边界，把敏感逻辑放进 Rust。在 MōBrowser 里，这意味着用好内置的保护模型，并对留在它之外的东西保持审慎。
最重要的是，明确你究竟要防谁。"随意翻看"、"竞争对手的好奇"、"技术用户的打补丁"、"有决心的专业逆向"——这些根本不是同一种威胁模型。一个对前两者来说足够合理的工具，对最后一种可能依旧很弱。
总结
JavaScript 桌面应用中的源码保护不是一个"有或没有"的二元属性。它是打包、模糊化、完整性和架构的组合。
- Electron 给了你一个灵活的生态和多种加固技术，但你得自己把它们拼起来——光靠 ASAR 并不是保护。
- Tauri 主要通过信任边界和 Rust 侧的特权逻辑来提升安全叙事，而不是为发布出来的前端资产提供内置保护。
- MōBrowser 在打包侧走得更远，把源码和资源保护作为框架的内置能力。
但这一切仍然不能改变那个最深层的约束：必须在客户端执行的代码，只能被保护到某个程度。真正现实的问题是：你希望提取和篡改要付出多大的成本，以及你有多大能力从一开始就不把敏感逻辑以 JavaScript 的形态发布出去。
参考链接
- Electron ASAR 文档： www.electronjs.org/docs/latest…
- electron-vite 字节码编译： electron-vite.org/guide/sourc…
- Tauri 安全模型： tauri.app/security/
