Pake | 开源网页桌面化工具，一键生成轻量桌面应用

想把一个网页、HTML 文件或本地静态站点变成独立桌面应用，不一定要从 Electron 项目开始。Pake 用 Rust + Tauri 提供命令行打包器，输入网址或静态文件目录，经过一次构建即可输出 macOS、Windows、Linux 的应用包。项目本身采用 GPLv3，并为标准 Pake 构建流程生成的目标应用提供了单独的 Pake Output Exception；本文重点解释它能打包什么、怎样配置 CLI、哪些平台差异需要提前处理，以及“开源工具”和“生成的应用”在许可证上并不是同一件事。

截至 2026 年 9 月 2 日核对，GitHub 最新稳定 Release 是 V3.15.6，发布时间为 2026 年 8 月 8 日；main 分支的 package.json 版本已经是 3.15.7。仓库页面当时约有 6.12 万 stars 和 1.26 万 forks。版本号、下载包和页面统计会继续变化，实际构建前应以 Release 与当前文档为准。

Pake 解决的是“网页如何变成桌面应用”

Pake 的输入不只是一条线上网址。CLI 文档把以下三类内容都视为有效输入：远程网页 URL、单个本地 HTML 文件，以及根目录包含 index.html 的静态文件目录（例如前端项目的 dist/）。构建后得到的是带原生窗口和系统集成能力的桌面应用，而不是把网页简单另存为一个快捷方式。

环节	Pake 的处理	关键边界
输入	URL、HTML 文件或本地静态目录	本地单 HTML 默认不递归复制同目录资源，需要时加 `--use-local-file`
运行时	Rust + Tauri 原生窗口与系统 WebView	目标网页自己的登录、跨域和浏览器兼容性仍然存在
定制	名称、图标、窗口尺寸、标题栏、快捷键、代理等参数	不同系统支持的选项并不完全相同
输出	macOS DMG/App、Windows x64/ARM64、Linux 多种包格式	跨架构构建需要对应 Rust target 和系统依赖
分发	标准构建产物可按自己的许可分发	这是 Output Exception 的范围，不改变 Pake 自身 GPLv3 与商标规则

CLI 与在线构建：两种获取路径

本地 CLI：适合反复打包和精细配置

CLI 文档建议使用 Node.js 22 或更高版本；项目 package.json 的最低引擎要求是 Node.js >=20.9.0。本地构建还需要 Rust >=1.85.0，macOS/Linux 的依赖管理会用到 curl、wget、file 和 tar。满足条件后，可以通过 pnpm 或 npm 安装：

pnpm install -g pake-cli
# 或
npm install -g pake-cli

最小命令是 pake https://github.com --name "GitHub"，Pake 会尝试自动获取网站图标。第一次打包需要准备 Rust/Tauri 环境，官方文档提醒这一步可能明显慢于后续构建；如果不想在本机配置环境，可以改用仓库提供的 GitHub Actions 在线构建流程。

在线构建：不在本机安装 Rust

README 把 GitHub Actions 作为新手路径：在仓库页面填写网址、应用名、图标和构建参数，由云端工作流生成对应平台的安装包。它减少了本地工具链配置，但构建过程需要把目标网址、图标地址和配置提交给 GitHub；私有站点、含敏感参数的地址或有访问控制的内部系统，不应直接当作公开工作流输入。

参数不只是网址和应用名

Pake 的 CLI 以 pake [url] [options] 工作，常用参数直接对应桌面应用的外观和交互。下面这条命令把窗口尺寸、标题栏和系统托盘一起写入构建过程：

pake https://weekly.tw93.fun --name "Weekly" \
  --icon https://cdn.tw93.fun/pake/weekly.icns \
  --width 1200 --height 800 \
  --hide-title-bar --show-system-tray

窗口与导航：--width、--height、--min-width、--min-height、--zoom、--fullscreen 和 --maximize 控制初始窗口；--force-internal-navigation、--safe-domain 与 --internal-url-regex 决定哪些链接留在应用内。
系统集成：--show-system-tray、--start-to-tray、--hide-on-close、--activation-shortcut、--multi-instance 和 --multi-window 用于托盘、快捷键和窗口行为。
构建自动化：--json 让 stdout 只输出一个机器可读结果对象，--config app.json 用声明式配置替代长参数，pake ./dist --name MyTool 则可以直接包装本地构建产物。
本地文件与网页能力：--use-local-file 递归复制单个 HTML 的同目录资源，--enable-drag-drop、--wasm、--camera、--microphone 等选项按目标站点需要启用。

有一个容易忽略的限制：本地静态目录可以直接打包，但单文件或目录的 history-mode SPA 路由目前还没有得到完整支持，hash 路由更稳妥。应用名、图标和窗口参数也会参与平台适配，不能只在一个系统上验证后就默认其他系统表现完全相同。

桌面端差异与输出格式

macOS 默认生成 DMG；为了只生成可测试的 .app，可以设置 PAKE_CREATE_APP=1 或使用 --targets app，需要 Intel 与 Apple Silicon 通用包时使用 --targets universal。Windows 可指定 x64 或 arm64；Linux 的目标包括 deb、appimage、rpm、zst 及 ARM64 变体。Linux ARM64 交叉编译还需要额外的 gcc-aarch64-linux-gnu 等工具，不能把“支持平台”理解成在任何机器上都能无依赖交叉构建。

官方仓库 README 的演示 GIF 展示了 Pake CLI 编译 Rust 依赖、生成应用并打开安装包的过程。下面的画面从该官方演示素材提取，终端里的版本和路径属于 GIF 录制时点，不代表当前 V3.15.6 Release 或 main 分支；本文也没有在本地执行打包。

Pake 官方命令行打包演示画面 — Pake 官方 README 演示 GIF 的打包完成画面；终端版本、路径和桌面图标属于演示录制时点，不代表当前版本。来源：https://raw.githubusercontent.com/tw93/static/main/pake/pake1.gif

“轻量”和 Tauri：项目卖点应该怎样理解

Pake README 将安装包“通常低于 10M”、相较 Electron 包体“接近 20 倍更小”列为轻量化卖点，并把更低内存占用和更快启动归因于 Rust/Tauri。这里的数字和性能表述来自项目自己的介绍，不是本文的独立基准测试；实际体积还会受目标平台、WebView、图标、网页资源和打包参数影响。更稳妥的理解是：Pake 选择系统 WebView 与 Rust 原生壳，减少了把完整 Chromium 运行时随应用分发的路径，但网页本身的资源加载和运行开销仍然存在。

安全、权限与网络边界

Pake 打包的是网页容器，登录状态、Cookie、Local Storage、请求内容和站点权限取决于目标网页与所选 WebView。需要临时隔离本地浏览数据时可以使用 --incognito；这个选项会阻止 Cookie、Local Storage 和浏览历史持久化，但不等于目标网站不会收到请求或不保存服务器端数据。

CLI 还提供 --proxy-url、--basic-auth、--camera、--microphone 和 --ignore-certificate-errors 等能力。摄像头、麦克风和 Basic Auth 只应在目标应用确实需要时启用；--ignore-certificate-errors 会降低 TLS 证书校验强度，适合排查内网或自签名环境，不应作为公开服务的默认配置。不要把带有 Token、内部地址或私密查询参数的 URL 写入公开构建日志。

GPLv3、Output Exception 与品牌边界

Pake 自身使用 GPL-3.0-or-later。仓库的 LICENSE-EXCEPTION 又规定：如果使用 Pake 的标准构建和打包流程生成目标应用，嵌入目标应用的 Pake 部分不会仅因自身存在就让整个目标应用自动受 GPLv3 约束，生成的应用可以按自己的许可条款分发。这项例外针对的是标准打包产物，不是对 Pake 源码本身或改造后的 Pake 分支的豁免。

如果你修改 Pake 源码后再分发 Pake 或其衍生项目，仍需遵守 GPLv3。与此同时，TRADEMARK.md 把“Pake”和 Pake Logo 视为项目商标，建议 fork 或衍生产品使用自己的名称和图标，不要让用户误以为得到 Pake 官方背书。生成的桌面应用还必须分别遵守被包装网站、图标素材和第三方内容的版权、商标与服务条款。

维护状态与使用取舍

Pake 的适用场景很具体：需要把一个已经可用的 Web 产品变成独立窗口、希望统一图标和快捷键、或需要批量输出多平台安装包时，CLI 参数和 GitHub Actions 能减少重复壳代码。如果目标只是给自己的网站加一个快捷入口，浏览器安装 PWA 或系统快捷方式可能更省事；如果网页依赖 history-mode 路由、复杂浏览器扩展或嵌入式登录策略，则应先做目标站点验证，而不是把“能打开网页”当成完整兼容承诺。

版本维护上，Release 页面与 main 分支存在一个值得记录的差异：稳定下载入口是 V3.15.6，而源码包已经进入 3.15.7。需要可复现构建时应锁定 Release 或明确 commit，并同步保存 Node、Rust、目标架构和 CLI 参数；不要在自动化流程中无条件追随浮动的“latest”包。