上周我们组想把内部 OA 系统塞进一个桌面客户端，方便同事不用每次都开浏览器、登两次账号。组长第一反应是：上 Electron 吧。
我打开终端 npm install electron ，然后……一下午就没了。环境不对、版本冲突、打包出来的 dmg 比我们整个 OA 还大。
后来我在 GitHub 上翻到一个叫 PakePlus 的项目，抱着"又来一个 Electron 套壳吹牛皮"的心态点进去，结果真香了。今天这篇不是软文，是我用了一阵之后的真实记录，好处和坑都摊开讲。
它到底是什么来头
先说清楚身份： PakePlus ，早期在 README 里还叫 PacBao ，两个名字现在还混着用（作者自己都承认命名有点随意）。它基于 Rust + Tauri 2 构建， MIT 协议 ，2024 年 9 月 10 日创建，到 2026 年 7 月已经拿了 13,733 个 Star、 6,051 个 Fork，Open Issues 只有 10 个——这个 issues 数量对于一个这么火的项目，说明维护得还挺勤。
仓库：github.com/Sjj1024/PakePlus
官网：pakeplus.com
支持：Windows / macOS / Linux / Android / iOS
实时数据（抓取自 2026-07-18 GitHub API）：
⭐ Stars 13,733
Forks 6,051
⚖️ MIT License
Release 动态
它凭什么敢说比 Electron 强？
先泼一盆冷水：下面这几条是 项目方自己的宣传数据，我没独立验证过 ，你们自己掂量：
应用体积比 Electron 小约 20 倍 ，号称 小于 5MB （官方数据）
性能比 Electron 快约 10 倍 （官方数据）
不需要本地复杂环境，云端（GitHub Actions）或本地都能打包
本地打包不用 GitHub Token，大约 30 秒 搞定
⚠️ 口径说明：以上"20倍 / 小于5MB / 快10倍"均为 PakePlus 官方 README 宣传口径，非本号独立实测结论。
这几个点只要有一半是真的，对前端同学就够香了。毕竟谁没被 Electron 的体积和启动速度折磨过。
真正让我留下的，是它能往网页里塞 JS
PakePlus 的核心玩法之一是 自定义 JS 注入 。你打包一个网页的时候，可以顺手塞一段自己的脚本进去，比如自动登录、去广告、自动填表、各种自动化。
更狠的是，它支持在 JS 里直接调用 系统级 API ——下载文件、执行命令、开新窗口，这些原本得写原生代码才能干的事，在注入的 JS 里就能调。还有 调试模式 ，打包后右键就能开。
另外它支持把 Vue/React 编译后的 dist 或者一个 index.html 直接丢进去打包，也支持 中文应用名 。前端同学最舒服的一点是：静态文件打包这条路，基本零门槛。
给个真实能跑的思路（官方文档里的玩法，我整理成示意）：
// 在 PakePlus 的 JS 注入里，可注入自定义脚本
// 示例：隐藏页面指定广告元素
document.querySelectorAll( '.ad-banner, .popup-ad' ).forEach(el => el.remove);
// 示例：页面加载后自动填充并登录
window.addEventListener( 'load' , => { const user = document.querySelector( ' #username ' ); const pass = document.querySelector( ' #password ' );
if (user && pass) {
user.value = 'your_account'; pass.value = 'your_password'; }
});
它和 Electron、Tauri、Pake 到底差在哪？
下面这张表来自掘金上一个哥们的实测对比（ 第三方评测，非官方 ），我觉得比较实在：
维度
PakePlus
Tauri
Electron
Pake
依赖环境
不需要
需要(Rust+)
需要(Node)
需要(Rust+)
从无到有
分钟级
小时级
小时级
分钟级
桌面端体积
支持(约5M)
支持(约5M)
支持(50M+)
支持(约5M)
移动端
支持(约5M)
支持(约39.5M)
不支持
不支持
需懂编程
不需要
需要
需要
不需要
中文名
支持
不支持
支持
不支持
界面化操作
支持
不支持
不支持
不支持
数据 PakePlus 官方背书）。表中"本地体积约10M"指含依赖的本地环境，"小于5MB"是产物体积，别混了。
看得出来，PakePlus 基本是冲着"让不懂 Rust 的前端也能玩 Tauri"这个方向去的。它把 Tauri 的能力用 GUI 和云端流水线包了一层，代价是本地环境比纯 Tauri 大一点。
三个坑，官方没主动喊，但你得知道
写工具测评我最烦一通吹的。这项目有几点必须提前说清，省得你踩了才骂街。
坑一
云端打包会偷偷给你的仓库自动 star。
对，你没看错。用 GitHub Token 走云端打包时，项目会 自动给你的仓库点一个 star ，这是官方 README 自己写明的。作者大概是为了推广，但这个行为对很多用户来说是"意料之外"的。用之前心里有个数，别到时候发现仓库多了个 star 一脸懵。
坑二
前端代码已经停止开源。
这也是 README 里明说的——因为有人拿它打包违规、甚至非法的软件，违背了作者做这东西的初衷，所以 前端代码以后不再开源 ；如果这类事再发生，作者放话会全面闭源。
这点我反而觉得作者挺刚的，但也说明：你现在能拿到的前端源码是最后的开源版本，后续更新你只能用打包好的，看不到实现细节了。用之前权衡下。
坑三
Mac 上没买官方签名，安装会报"已损坏"。
作者没花那个 $99/年的开发者签名费，所以你在 Mac 上装完第一次打开，系统大概率甩你一句"App 已损坏，无法打开"。不是真坏了，是没签名。手动跑一条命令绕过就行（ 仅用于你自己合法打包的应用 ）：
sudo xattr -r -d com.apple.quarantine /Applications/PakePlus.app
把 /Applications/PakePlus.app 换成你实际装的路径。这条命令就是告诉 macOS"别隔离这个 app"，属于每个第三方 Mac 小工具都会遇到的老问题，不算项目 bug，但新手容易被吓退。
想自己改？本地跑起来也简单
如果你想本地折腾，仓库里的命令很标准（要求 Rust ≥ 1.63, Node ≥ 16 ）：
# 安装依赖
pnpm i
# 本地开发（右键开启调试模式）
pnpm run dev
# 打包应用
pnpm run build
不过前面说过，前端代码已经不开源了，所以本地 build 能跑，但你能改的范围有限，这点心里要有数。
至于云端打包用的 GitHub Token 权限（classic 版），官方要求的是这两块：
repo: Fork and manage template code
workflow: Compile and release your software
beta 版要的权限更细（repo 的 Fork / Actions 管理 / Contents / Issues），如果你走 beta 路线按 README 配就行。界面截图我就不硬贴了——官网 pakeplus.com 和 GitHub 仓库里有真实截图，比我文字描述直观，建议直接去瞄一眼。
用了一阵，我的态度很明确： 对想快速把网页 / 前端项目变成多端 App、又不想啃 Rust 的前端同学，PakePlus 值得一试；但它不是 Electron 的完美替代，更像是一个"够用就好"的捷径。
体积和入门门槛确实是真香点，GUI 化打包对非原生开发者太友好了。但自动 star、前端闭源、Mac 签名这几个点，说明它还带着明显的个人项目特征——灵活、有棱角、但规矩没那么"公司级"。你如果接受这些，它大概率能省你几十个小时；接受不了，Tauri 永远是更"正经"的选择。
你最想把哪个网站 / 网页打包成 App？或者—— 自动 star 这事儿，你觉得算不算过度？ 评论区聊聊，我去翻翻你们的脑洞。
补充一个正文没展开的点：PakePlus 早期叫 PacBao，README 里两个名字现在还混着出现，第一次看的人别以为下错了仓库。另外想看真实界面截图的直接去官网 pakeplus.com 或 GitHub 仓库，比文字描述直观。自动 star 那事你们怎么看？我觉得作为开源作者想推广能理解，但默认静默 star 还是该在界面上给个勾选框，让用户自己选——你们觉得呢？
热门跟贴