两种方式对比——云端还是本地，一次选准
一张表说清楚
| 维度 | 云端打包（GitHub Actions） | 本地打包 |
|---|---|---|
| 需要 Token | ✅ 需要 classic token（或 OAuth 授权） | ❌ 不需要 |
| 平台 | 一次出所有平台（Win/macOS/Linux/Android/iOS） | 仅当前系统一个平台 |
| 耗时 | 3-10 分钟 | 30-60 秒 |
| 本地依赖 | 零（Rust/Tauri/编译链在 GitHub Runner） | 零（PakePlus 内置） |
| 跨平台编译 | 自动并行 | 不支持 |
| 文件大小限制 | GitHub 仓库 100MB / Release 2GB | 无限制 |
| 产物托管 | GitHub Release 页面自动生成 | 本地输出目录 |
| 发布历史 | 自动记录在 PakePlus 发布历史面板 | 无（需自己管理） |
| 在线网站发布 | ✅ 一键推 GitHub Pages | ❌ 不支持 |
| 私密/公开项目 | 都支持 | 本地私有 |
| 数据安全 | 项目在你自己的 GitHub 仓库 | 全程本地，零外联 |
| 网络要求 | 需要访问 GitHub | 首次需下载缓存，后续可离线 |
按场景选
场景一：快速原型演示
选本地打包。写了一个小工具、改了一个 Vue 组件，给同事演示——30 秒出一个安装包，比等 GitHub Actions 跑一圈快太多。
场景二：正式发布、多平台分发
选云端打包。用户可能在 Mac、Windows、Linux 上都有——一次点发布，GitHub Actions 并行编译三个平台的包，上传到 Release 页面，分发链接直接给用户。
场景三：没有 GitHub 账号或不想给权限
选本地打包。PakePlus 的本地模式不强制要求注册 GitHub——下载客户端就能用，零门槛起步。
场景四：公司内网、屏蔽 GitHub
选本地打包。很多公司内网限制 GitHub 访问（HTTPS 443 端口、代理认证等），云端打包会卡在推送阶段或 Actions 触发阶段。本地打包完全绕开外网依赖。
场景五：Unity WebGL / Cocos 大项目
选本地打包。WebGL 构建产物通常几百 MB，GitHub 仓库推送会超 100MB 限制（GitHub 会拒绝推送）。本地打包无文件大小限制。
场景六：需要 GitHub Pages 免费建站
选云端打包。只有有 GitHub 仓库才能用 Pages。从 PakePlus 右上角菜单里点"在线网站"一键发布。
场景七：个人隐私极度敏感
选本地打包。项目配置、dist 文件、编译过程——全程本地，不涉及任何外部服务。对于需要处理敏感数据的场景更安全。
场景八：没有外网 / 离线环境
选本地打包。首次使用需要联网下载编译缓存（一次性），之后可以完全离线打包。云端打包无法离线工作。
可以混用吗
可以——同一个项目，先用本地打包快速出原型、调配置，确认没问题后再切云端打包出多平台正式版。PakePlus 的项目配置和 dist 文件是通用的，两条路径共享。
混用的好处
| 阶段 | 方式 | 原因 |
|---|---|---|
| 开发调试期 | 本地 | 快速迭代，改配置 30 秒见效果 |
| 小范围测试 | 本地 | 给几个同事测试，不用等云端 |
| 正式发布 | 云端 | 一次出全平台、自动 Release 页面、有发布历史 |
首次使用的推荐路径
第一次用 PakePlus 时，建议按这个顺序走，能快速理解两条路径的区别：
- 先本地打包一个已知网站（比如 对应的访问地址）→ 30 秒出包 → 理解本地流程
- 再去 GitHub 创建 token → 配置好 → 云端打包同一个项目 → 等几分钟 → 理解云端流程
- 根据实际需求决定哪条路径为主
两条路径都跑一遍，比看文档更直观。
关于"本地打包速度更快"的误区
有人会觉得"本地打包 30 秒比云端 10 分钟快"，所以应该优先选本地。但这个"更快"只在单平台下成立：
- 需要 Windows 包 → 本地 30 秒 ✅
- 需要 Mac + Windows → 本地两次 = 60 秒 vs 云端一次 5 分钟 → 本地快
- 需要 Mac + Windows + Linux → 本地三次 = 90 秒 vs 云端一次 6 分钟 → 差别不大
- 需要五平台 + Android + iOS → 本地七次 = 3.5 分钟（假设每次 30 秒且跨平台能做到，实际上不可能）vs 云端一次 10 分钟 → 云端更省事
多平台数量越多，云端的优势越明显。