同时编译多平台——一次发布怎么产出五份安装包
"一键出多平台"是什么意思
PakePlus 的云端打包模式有一个核心卖点：一次发布，GitHub Actions 自动并行编译所有平台，等 3-10 分钟后去 Release 页面一次性拿齐所有安装包。
不需要在 Windows 上打一份、macOS 上再打一份、Linux 上再打一份——全部由 GitHub 云端 Runner 并行跑完。
并行编译的技术原理
GitHub Actions Matrix Strategy
GitHub Actions 的 strategy.matrix 功能允许在一个 workflow 里定义多个并行任务：
# 伪代码：PakePlus 模板里可能的结构
strategy:
matrix:
os: [windows-latest, macos-latest, macos-13, ubuntu-latest, ubuntu-22.04-arm]
include:
- os: windows-latest
runner: self-hosted-x64
# ... 更多配置每个 os 值对应一个独立的 GitHub Runner，它们同时启动、同时编译、互不干扰。
Runner 的选择
| 平台 | GitHub Runner | 说明 |
|---|---|---|
| Windows x64 | windows-latest | Windows Server 2022，x64 架构 |
| Windows ARM64 | 自托管或第三方 | GitHub 官方不提供 ARM64 Windows Runner |
| macOS Apple Silicon | macos-latest | M1/M2/M3 架构 |
| macOS Intel | macos-13 | 最后一个 Intel macOS Runner（High Sierra） |
| Linux x64 | ubuntu-latest | Ubuntu 22.04 x64 |
| Linux ARM64 | ubuntu-22.04-arm | Ubuntu ARM64 模拟 Runner |
| Android | Linux Runner + Android NDK | 在 Linux 上编译 APK |
| iOS | macos-latest | 用 Xcode 编译 IPA |
并行 vs 串行
假设一次发布要编译 6 个目标：
| 方式 | 每个目标耗时 | 总耗时 |
|---|---|---|
| 串行 | 3 分钟 | 18 分钟 |
| 并行 | 3 分钟 | 3 分钟（取最慢那个） |
并行编译把"线性累加"变成"取最大值"——目标数量越多，优势越明显。
产物命名规则
GitHub Release 页面会自动为每个产物生成文件名，通常遵循：
{软件名}_{版本号}_{平台}_{架构}.{扩展名}示例：
PakePlusDemo_1.0.0_x64-setup.exe ← Windows 安装版
PakePlusDemo_1.0.0_win-x64.zip ← Windows 绿色版
PakePlusDemo_1.0.0_aarch64.dmg ← macOS Apple Silicon
PakePlusDemo_1.0.0_x86_64.dmg ← macOS Intel
PakePlusDemo_1.0.0_amd64.deb ← Linux deb
PakePlusDemo_1.0.0_amd64.AppImage ← Linux AppImage
PakePlusDemo_1.0.0_arm64.deb ← Linux ARM64
PakePlusDemo_1.0.0.apk ← Android APK
PakePlusDemo_1.0.0.ipa ← iOS IPA文件名由 PakePlus 模板的 workflow 自动生成，用户不需要手动命名。
macOS 通用二进制
macOS 同时编译 Apple Silicon 和 Intel 后，会自动合成一个 Universal Binary（通用二进制）——用户下载一个 .dmg，在 M 系列 Mac 和 Intel Mac 上都能原生运行，不需要 Rosetta 转译。
这是 GitHub Actions Runner 的优势：一次发布同时出两种架构的包，PakePlus 模板自动做合成。
移动端打包的额外注意
移动端（Android / iOS）打包有额外的注意事项：
Android
- GitHub 上需要 Android NDK 和 Gradle 的编译环境（workflow 自动处理）
- APK 签名：调试包自动用 debug keystore；正式分发需要自己准备 release keystore（PakePlus 标注"仅限个人使用"）
- 产物是标准 APK，可直接安装或上传到应用商店
iOS
- iOS 编译必须在 macOS Runner 上完成（需要 Xcode）
- PakePlus 支持免签——不需要 Apple 开发者账号也能出 IPA
- 免签 IPA 的安装方式：
- 通过第三方工具（如 AltStore）安装到 iOS 设备
- 企业分发（需要 Apple Enterprise 账号，PakePlus 不负责这个）
- TestFlight 上传分发
同时编译的资源消耗
同时编译多个平台时，GitHub Actions 的使用量会快速累积：
| 平台组合 | 一次发布消耗的分钟数 |
|---|---|
| 仅桌面三平台（Win+Mac+Linux） | 约 15 分钟 |
| 桌面 + Android | 约 20 分钟 |
| 全平台（桌面 + Android + iOS） | 约 30 分钟 |
| 每月免费额度 | 2000 分钟 |
| 每月约可发布 | 60-130 次 |
超出免费额度需要升级 GitHub Pro（$4/月，5000 分钟/月）或 Team（$4/人/月，额外额度）。
部分失败的处理
并行编译时，可能某个平台成功了、另一个失败了：
- 成功的产物：正常上传到 Release
- 失败的产物：PakePlus 发布历史面板里会显示失败的那个 Runner 的日志
- 重新发布：整个 workflow 重新跑一遍（GitHub Actions 不支持只重跑某一个失败的 Job）
本地为什么做不到
本地无法同时编译多平台，根本原因有两个：
- 平台限制：macOS 上可以编 Windows（需要交叉编译环境），但 Windows 上不能编 macOS（Apple 的 EULA 限制），任何系统上都不能编 iOS（必须 Xcode）
- 依赖复杂：每增加一个编译目标就要下载安装一套编译工具链，本地硬盘很快被撑爆
GitHub Actions 云端天然绕过了这两个问题——五个操作系统各有一个 Runner，各自装各自的依赖，互不干扰。