[Github] Pake – 一条命令把网页打包成跨平台桌面应用

Pake 解决的是一个很具体的桌面开发问题：你已经有一个网站、单页 HTML 或前端构建目录，却不想为了一个独立窗口重新维护一套 Electron/Tauri 工程。它用 Tauri、Rust 和系统 WebView，把网页打包成 macOS、Windows、Linux 安装包，入口可以是 URL，也可以是本地静态文件。真正的判断标准不是“能不能生成安装包”，而是你的页面能否接受 WebView 的路由、登录、权限和浏览器兼容边界；本文依据 Pake 官方仓库、文档、Release 和许可证文件整理，截至 2026 年 8 月 30 日未在本机执行打包测试。

它打包的是什么

Pake 不是把网页代码翻译成原生控件，也不是替你重写一个桌面版前端。它在桌面窗口里加载目标网页或本地静态内容，再借助 Tauri 的 Rust 外壳提供安装包、菜单、托盘、快捷键、窗口尺寸、下载和部分系统能力。README 将它定位为“用一条命令把网页变成桌面应用”，并强调使用系统 WebView；项目自述的“小于 10M”主要描述安装包或磁盘体积，不应理解为运行时只占用几兆内存。

这条边界反而决定了 Pake 的适用性：资讯站、后台工具、文档、在线编辑器、个人工作台和内部系统，往往只需要一个独立窗口与安装入口；需要深度原生集成、复杂离线能力或完全控制渲染引擎的产品，则不能只靠 Pake 的包装层解决。

先跑通一条命令

网页与本地目录

CLI 的最短路径是先安装 pake-cli，再把 URL 交给 Pake：

pnpm install -g pake-cli
pake https://github.com --name GitHub

不想使用 pnpm 时，官方文档也提供 npm install -g pake-cli；没有全局安装权限，可以改用 npx pake-cli。URL 之外，Pake 也接受单个 HTML 文件，或根目录包含 index.html 的静态目录：

pake ./page.html --name MyStaticApp --use-local-file
pake ./dist --name MyTool

本地目录适合把 React、Vue 或其他前端项目的构建产物直接交给打包器，但官方文档明确区分了路由能力：hash 路由可以工作，history-mode SPA 路由目前不支持。若网站依赖同级 CSS、JavaScript 或图片，单文件路径可以配合 --use-local-file；目录打包则应确保完整资源树和根目录入口都已进入 dist。

先看环境门槛

当前仓库的开发说明要求 Rust >=1.85，README 推荐 Node.js >=22，而 pake-cli 的 package.json 将 Node 引擎下限标为 >=20.9.0。CLI 在缺少 Rust 时会尝试引导安装，但首次构建仍会下载和编译依赖；这不是点击一次命令就完全绕开的环境成本。macOS、Windows 和 Linux 都能作为构建目标，但每个平台的系统 SDK、WebView、打包工具和签名流程仍然由对应平台决定。

在线构建怎么走

如果本机不想准备 Rust、Node 和 Tauri 依赖，Pake 官方还提供 GitHub Actions 路径：先 Fork 项目，进入自己仓库的 Actions，选择 Build App With Pake CLI，填写平台、URL、应用名称以及可选图标、窗口尺寸和 Linux 目标格式，再从运行结果的 Artifacts 下载安装包。官方文档给出的时间参考是首次运行约 10–15 分钟，建立缓存后后续运行约 5 分钟，缓存本身约 400–600MB。

在线构建的优势是把环境准备交给 CI，代价是构建输入、缓存、Artifact 和 GitHub 权限都进入另一条链路。它更适合偶尔打包、团队共享配置或不想在个人电脑上安装 Rust 的用户；需要频繁调试注入脚本、修改 Tauri 核心或检查本地系统行为时，本地 CLI 会更直接。

窗口还能改什么

尺寸、图标与边框

常用参数围绕“像不像一个独立应用”展开：--name 设置应用名，--icon 指定图标，省略时可以尝试自动获取网站图标；--width、--height 控制初始窗口尺寸，--fullscreen、--always-on-top、--maximize 和 --dark-mode 改变启动行为。macOS 可以使用 --hide-title-bar，Windows/Linux 则对应 --hide-window-decorations；系统托盘、关闭时隐藏、拖拽和多窗口也都有相应选项。

这些选项能处理桌面应用的外观和交互习惯，却不会改变网站内部的响应式布局。一个只为手机设计的页面，即使被放进 1200×780 的窗口，也可能仍然显示移动版内容；窗口参数解决的是容器尺寸，不是网页本身的断点策略。

注入脚本和静态文件

需要去掉广告、调整样式或补一小段快捷键逻辑时，可以通过 --inject 注入本地 CSS/JavaScript；更深的定制则进入仓库的 src-tauri/src/inject/ 和 Rust 代码。Pake 的高级文档还支持容器通信、拖拽、通知、代理、下载处理等扩展方向。判断是否该修改源码的分界线很清楚：只改变页面外观和少量行为，用注入文件即可；需要增加稳定的原生能力、修改窗口生命周期或维护自定义产品，就应把 Pake 当作 Tauri 项目来开发，而不是继续堆 CLI 参数。

路由和登录的边界

History 路由要先验证

URL 打包看起来最简单，但网页的导航模型会决定成品是否可用。官方文档明确支持本地静态文件和 hash 路由，history-mode SPA 路由目前不支持；这意味着把 dist 目录交给 Pake 前，最好先确认刷新、深层链接和回退路径。需要新窗口的登录、弹窗或外部流程时，可以尝试 --new-window、--multi-window 和 --safe-domain，但它们只是导航策略，不会把 WebView 变成完整浏览器。

WebView 登录并不等于浏览器登录

Pake FAQ 特别提醒，Google OAuth 等身份提供商可能拒绝嵌入式 WebView，即使打开了新窗口也不保证通过；Cloudflare 或机器人验证也可能因为 WebView 的浏览器特征而循环。--user-agent、--proxy-url 和 --basic-auth 能处理一部分站点环境，不能绕过服务商政策。对于需要摄像头、麦克风的 macOS 应用，构建时还要显式使用 --camera 或 --microphone 申请权限。

如果目标站点把 Cookie 或本地存储当作登录前提，--incognito 需要谨慎使用：它能避免持久化存储带来的某些登录问题，但每次启动都可能要求重新认证。对企业内部系统，应该把认证回调、域名范围和数据留存策略先验证清楚，再决定是否把站点封装成可分发的桌面应用。

自动化要用 JSON

配置文件承载重复参数

当一个团队需要为多个站点重复打包，命令行长参数很快会变得难以审查。Pake 支持 --config app.json，用声明式文件保存 URL、名称、窗口、目标格式和权限选项；配置字段使用 camelCase，命令行显式参数优先于配置文件，未知字段会快速失败，配置里的相对路径按进程当前工作目录解析。

{
  "url": "https://example.com",
  "name": "Example",
  "width": 1200,
  "height": 780,
  "newWindow": true,
  "targets": "deb,appimage"
}

机器结果和退出码

脚本或 AI agent 调用 Pake 时，应加上 --json，不要解析面向人的进度文本。官方 llms.txt 约定 stdout 输出一个 JSON 对象，包含 ok、平台、架构、产物路径、文件大小、格式、警告和错误信息，日志走 stderr；退出码 0 表示成功，2 表示输入无效，3 表示构建失败，4 表示环境或依赖缺失，1 表示未知错误。Linux 多目标构建时，即使 ok 为 true，也应继续检查 outputs[].format，因为某个格式可能失败而其他格式仍然生成。

生成应用后怎么理解

Pake 输出的核心仍然是“网页内容 + 原生窗口壳”。官方 README 列出了 WeRead、Twitter、Grok、DeepSeek、ChatGPT、Gemini、YouTube、Notion 等示例包；它们展示的是把常用网站放进独立窗口、统一快捷键和安装入口，而不是将网站改造成离线原生客户端。安装包体积可以很小，但加载重型 SPA 时，内存主要由系统 WebView 和网页本身决定。

因此，Pake 更适合“把已有网页变成可安装入口”，而不是“用网页技术替代原生产品设计”。如果你需要离线缓存、系统级文件关联、复杂后台任务、稳定的原生通知或可控的浏览器内核，应该把这些需求单独列出评估；否则，独立窗口、图标、托盘和跨平台安装包已经足以覆盖很多个人工具和内部应用场景。

许可证与版本

GPL 与输出例外

Pake 仓库本身采用 GPL-3.0，并且单独提供 LICENSE-EXCEPTION。这个例外针对标准 Pake 构建和打包流程生成的目标应用：Pake 代码被带入输出应用这一事实，不会自动让整个输出应用必须采用 GPLv3，生成应用可以按自己的条款分发。但这个例外不适用于 Pake 本身或对 Pake 源码进行超出标准配置/打包的修改；如果你要 fork Pake 做成自己的产品，仍需遵守 GPLv3，并按 TRADEMARK.md 更换产品名称和图标、避免暗示官方背书。

Release 与主分支

截至 2026 年 8 月 30 日，GitHub 仓库页面显示 61,159 Stars、12,570 Forks 和 1 个开放 Issue，最近推送时间为当天；近期提交覆盖 macOS 多窗口标签、Basic Auth、Linux 登录导航和 X 搜索布局等问题，说明项目仍在持续维护。当前 GitHub Release 页面最新标签是 V3.15.6 Anchor，发布于 2026 年 8 月 8 日，而仓库当前 package.json 的版本字段已经是 3.15.7。这两个数字不是同一个发布物：要复现构建或锁定依赖时，应明确选择 Release、npm 包或主分支来源。

结论与官方入口

Pake 值得推荐给三类人：已经有可用网页或前端构建产物、只需要一个独立桌面入口的个人开发者；需要把内部系统快速分发给团队的工程师；以及希望用 GitHub Actions 生成跨平台安装包、又不想维护完整桌面工程的人。它的关键收益是缩短“网页到安装包”的路径，而不是消除 Rust、平台 SDK、签名、WebView、登录和路由这些现实条件。

最稳妥的试法是先用一个公开、无需复杂登录的页面跑通 URL 打包，再测试本地 dist、刷新深层路由、文件下载、弹窗、Cookie、摄像头/麦克风和目标平台安装。确认网页与 WebView 的边界都能接受后，再把参数迁移到 app.json 或 GitHub Actions；如果需求已经接近原生应用，就不要把 Pake 的小安装包误当成完整原生能力。

• Pake GitHub 仓库
• CLI 使用指南：https://github.com/tw93/Pake/blob/main/docs/cli-usage.md
• GitHub Actions 在线构建：https://github.com/tw93/Pake/blob/main/docs/github-actions-usage.md
• 高级用法：https://github.com/tw93/Pake/blob/main/docs/advanced-usage.md
• FAQ：https://github.com/tw93/Pake/blob/main/docs/faq.md
• 最新 Release：https://github.com/tw93/Pake/releases/latest
• 官方产品页：https://yobi.tw93.fun/projects/pake
• npm CLI 包：https://www.npmjs.com/package/pake-cli