## 摘要

> 前端项目直接交付，源码几乎是裸奔的。本文从问题出发，分析 Electron/ASAR 打包的局限，讨论 Web 应用商业交付时源码保护、机器码授权、试用期控制三个环节的设计取舍，并给出效果对比。文中的思路来自我在做的工具 **封码 LockCode** 的实践沉淀。

---

## 正文

### 一、先说问题：前端交付，源码为什么是裸奔的

做过外包的应该都遇到过这个场景：

项目做完了，客户要求先试用。你把代码部署到服务器，或者直接发了个 dist 压缩包。结果：

-   **F12 一开，源码全裸。** HTML、JS、CSS 明文暴露，浏览器的“Save All Resources”一键就能拿到完整项目。
    
-   **ASAR 只是纸糊的。** 就算用 Electron 打成 EXE，一条解包命令就能还原出原始文件。
    
-   **试用期形同虚设。** 改个系统时间，试用期就绕过去了。
    
-   **尾款收不回来。** 客户拿到完整代码，拖着不付尾款，你没有任何技术手段制约。
    

这不是危言耸听。ASAR 的设计初衷是“方便分发”，不是“保护源码”——它本质是一个拼接归档，不是加密格式。很多开发者以为“打成 EXE 就安全了”，其实只是换了个文件后缀。

那有没有办法，让交付出去的 EXE **源码提取门槛足够高、授权绑定机器、试用期无法绕过**？

有。这篇文章聊聊其中的设计取舍。文中的思路，大部分来自我在做的工具 **封码 LockCode** 的实现过程中踩过的坑。

---

### 二、选型：为什么不是 Electron

先给结论：**Electron 能打包，但不是商业交付的最佳选择。**

| 维度 | Electron | 基于系统 WebView 的方案 |
| --- | --- | --- |
| 安装包体积 | 80-150 MB（自带 Chromium） | **3-10 MB**（用系统 WebView） |
| 内存占用 | 每个窗口一个 Chromium 进程 | **低一个数量级** |
| 资源保护 | ASAR 易解包 | **可做到加密 + 运行时不解密到磁盘** |
| 启动速度 | 较慢 | **秒级** |

Electron 的优势是生态成熟、开发零门槛，代价是**体积大**，而且**源码保护的主动权不在你手里**——ASAR 是框架决定的格式，你很难在它上面做文章。

基于系统 WebView 的方案（Windows 上是 WebView2，跨平台可以用 Tauri），体积天然轻量，更重要的是：**资源怎么存、怎么加载、加载后放哪，完全由你控制**。这才是做源码保护的前提。

这也是 **封码 LockCode** 最终选择的技术路线：Tauri 做后端，WebView2 做 Windows 渲染。选型阶段对比过 Electron、NW.js、Neutralino 几条路，最后落在 Tauri 上，原因就是上面这几点。

---

### 三、源码保护：核心是“不落盘”

#### 3.1 传统方案的漏洞在哪

大多数打包工具的做法是：把前端资源压缩成一个包，运行时**释放到临时目录**再加载。

这个思路有个根本问题：**只要文件落到磁盘，就有被拿到的可能。** `%TEMP%` 目录、用户目录、缓存目录，随便哪个位置被翻出来，明文全在。

#### 3.2 设计目标

**封码 LockCode** 在这块的设计目标很明确：**前端资源在磁盘上永远是密文，解密只发生在内存里，加载完立即释放。**

具体怎么加密、用什么模式、密钥怎么管理，这部分是方案的核心，我不展开——说出来对做保护的人没好处。但可以讲清楚**设计约束**：

-   资源在构建阶段就被加密，安装包里找不到任何明文 HTML/JS 关键词。
    
-   运行时通过自定义协议拦截 WebView 的资源请求，解密后的内容直接喂给渲染引擎，**不产生临时文件**。
    
-   加密算法带完整性校验，密文被篡改会直接解密失败，不会加载出坏页面。
    
-   配合禁用开发者工具、右键菜单、另存为，普通用户没有下手的地方。
    

这套约束听起来简单，实际做的时候细节很多：资源索引怎么组织、大文件怎么流式处理、字体和图片这类二进制资源怎么走同一条解密链路、开发模式和发布模式怎么切换。**封码 LockCode** 在早期版本里踩过“开发时能跑、打包后字体丢字”这种坑，后来才把资源管线整条理顺。

#### 3.3 诚实地说：这不是“绝对安全”

任何纯客户端的加密，密钥最终都要出现在运行时内存中。对于有决心的逆向工程师，内存层面的提取理论上仍然可行。

**封码 LockCode** 在文档里对这一点也不藏着：目标是**拦住绝大多数普通用户和一键解包脚本**，不是“绝对不可破解”。如果你的项目安全要求极高（比如核心算法本身就是卖点），建议结合服务端校验，把关键逻辑放到云端。

**定位要诚实**：它显著提高了提取门槛，让“随便谁下载个工具就能拿到源码”变成“需要专业能力和时间成本”。对商业交付来说，这个门槛通常已经够了。

---

### 四、授权：让软件绑在客户的机器上

源码保护解决的是“别被看”，授权解决的是“别被白嫖”。

#### 4.1 对称加密做授权，为什么不行

很多工具用对称加密生成激活码：服务端和客户端用同一个密钥。

问题很直接：**密钥在客户端里，逆向出来就能伪造任意激活码。** 这不是“难度问题”，是“设计缺陷”。

#### 4.2 正确的方向：非对称签名

非对称签名的思路是：签发授权用**私钥**（只在你手里），验证授权用**公钥**（内置在客户端）。

-   私钥永远不出现在客户端。
    
-   攻击者拿到公钥也无法伪造签名。
    
-   签名同时绑定机器标识和应用标识，**授权不能跨机器、跨应用复用**。
    

**封码 LockCode** 在授权模块上就是按这个方向做的。早期版本试过用对称加密图省事，后来发现这个思路根本守不住，才推倒重来换成非对称签名。这个切换的代价不小——授权文件格式、密钥管理、签发流程全要重做，但方向对了，后面就没再返工过。

具体用哪种签名算法、签名源怎么构造、密钥怎么保护，同样是方案核心，不展开。但设计目标可以讲：

-   授权文件与客户机器绑定，拷到别的电脑直接失效（一机一码）。
    
-   授权文件被篡改，签名验证失败。
    
-   同一个私钥签发的授权，不能拿到另一个应用上用。
    

#### 4.3 机器码的设计取舍

机器码的难点在于**稳定性**：换硬盘、换网卡、重装系统，机器码不能变，否则客户正常换硬件就被锁死；但又要足够唯一，不能两台机器算出同一个码。

这需要在“稳定性”和“唯一性”之间做取舍。具体取哪些系统标识、怎么组合、怎么哈希，属于实现细节，不展开。

可以说的结论是：**优先用系统安装时生成、不随硬件更换而变化的标识**，而不是磁盘序列号这类容易变的来源。**封码 LockCode** 在最早一版里用的是磁盘序列号，结果客户换硬盘之后授权全失效，售后处理了好几例，后来才改成更稳定的标识来源。

---

### 五、试用期：防的是“删记录”和“改时间”

试用期控制看起来简单，实际是两个对抗。

#### 5.1 对抗“删记录”

如果试用记录只存一个文件，用户删掉就重置了。

思路是**多点冗余**：同一份记录存在多个位置（不同目录、不同存储形式），读取时做一致性聚合。删掉一个，其他还在，下次启动自动恢复。

更进一步，运行时也要有**自愈机制**：后台定期检查各存储位置，缺失的立即从内存恢复，防止“边用边删”。

**封码 LockCode** 在这一块上做得比较克制——冗余位置不是越多越好，存太多位置会拖慢启动、也会在卸载时留垃圾。找到一个“够用且不臃肿”的平衡点，是这块设计上最花时间的部分。

#### 5.2 对抗“改时间”

只记录“上次运行时间”是不够的。用户把系统时间调回昨天，简单的比较逻辑很容易误判为时区问题而放过。

正确的方向是维护一个**只增不减的时间戳**：记录历史见过的最大时间值，试用期基于这个值计算，而不是基于“当前时间减首次运行时间”。

这样：

-   把时间调到未来再调回来，最大值已经被记录，试用期直接算完。
    
-   把时间调到过去，与最大值的偏差过大，直接判定异常。
    

具体的判定阈值、容错窗口、异常处理策略，属于实现细节，不展开。**封码 LockCode** 在阈值这块调过几轮——太严会把时区切换误判成作弊，太松又拦不住故意回拨，最后落在“容忍小幅偏差、大幅回拨直接拒绝”的策略上。

#### 5.3 效果

启动时校验 + 运行时自愈 + 单调时间戳，三者配合，能覆盖“删文件重置”“改时间延长”“边用边删”这几类最常见的绕过手段。

---

### 六、效果对比

| 交付方式 | 源码提取 | 一机一码 | 试用期控制 | 防时间回拨 | 安装包体积 |
| --- | --- | --- | --- | --- | --- |
| 直接发 dist 压缩包 | ❌ 明文 | ❌ | ❌ | ❌ | 小 |
| Electron + ASAR | ⚠️ 一条命令解包 | ❌ | ❌ | ❌ | 150 MB+ |
| 普通打包工具（临时目录释放） | ⚠️ 临时目录可见 | ⚠️ 弱 | ⚠️ 易绕过 | ❌ | 5-10 MB |
| **封码 LockCode 方案** | **✅ 加密 + 不落盘** | **✅ 非对称签名** | **✅ 多点冗余 + 自愈** | **✅ 单调时间戳** | **3-10 MB** |

---

### 七、这套方案适合谁

-   **前端外包团队**：交付前保护源码，客户不结清尾款拿不到完整版。
    
-   **AI 代码开发者**：用 Cursor / Claude Code 生成的应用，打包成带授权的桌面软件交付。
    
-   **全景摄影师 / Krpano 项目**：加密交付全景图，解决本地播放黑屏。
    
-   **企业 IT / 内部工具**：把内部 Web 系统打包成离线可用的桌面客户端。
    
-   **独立开发者**：给客户提供 30 天试用版，到期引导购买正式授权。
    

这几类场景，都是 **封码 LockCode** 在打磨过程中接触得比较多的，方案里的很多细节就是被这些场景逼出来的。

---

### 八、关于封码 LockCode

上面这套思路，我在 **封码 LockCode** 里完整实现并打磨了一段时间。它不是一个大而全的产品，定位很窄：**把 Web / HTML / AI 生成的前端项目，打包成加密的 Windows EXE，带机器码授权和试用期控制。**

如果你正在做的项目也有类似需求——外包交付要保护源码、AI 生成的工具要发给客户试用、内部系统要离线分发——可以把 **封码 LockCode** 作为一个参考选项。

不是教程，也不是教程能解决的活。很多问题（资源管线、机器码稳定性、时间回拨阈值）只有真正做一遍、踩过坑，才知道边界在哪。**封码 LockCode** 的价值不在于“帮你打包”，而在于这些边界已经替你趟过一遍。

如果你想聊聊技术方案、讨论 Web 应用商业交付的设计取舍，或者想看看 **封码 LockCode** 现在的实现思路，都欢迎交流。不聊产品也能聊技术。

摘要 前端项目直接交付，源码几乎是裸奔的。本文从问题出发，分析 Electron/ASAR 打包的局限，讨论 Web 应用商业交付时源码保护、机器码授权、试用期控制三个环节的设计取舍，并给出效果对比。文中的思路来自我在做的工具 封码 LockCode 的实践沉淀。 正文 一、先说问题：前端交付，源码为什么是裸奔的 做过外包的应该都遇到过这个场景： 项目做完了，客户要求先试用。你把代码部署到服务器，

Tauri + WebView2 做 Web 应用商业交付：源码保护与授权的设计取舍

云计算

前端交付源码易被提取，Electron/ASAR打包仅换后缀不设防。本文从实践出发，拆解源码加密不落盘、非对称签名一机一码、多点冗余+单调时间戳控试用期三大设计取舍，对比效果并给出适用场景，为Web应用商业交付提供可落地的保护思路。

对称加密

密钥管理

服务器

Windows

2026上云采购 | AI焕新·智启新局

coding

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Tauri + WebView2 做 Web 应用商业交付：源码保护与授权的设计取舍-腾讯云开发者社区-腾讯云

Tauri + WebView2 做 Web 应用商业交付：源码保护与授权的设计取舍

Tauri + WebView2 做 Web 应用商业交付：源码保护与授权的设计取舍

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐