用途
该技能面向使用现代桌面打包工具的多平台桌面应用项目，指导如何把 GitHub Actions 发布流程组织成「一个重型交叉构建 job + 一个轻量 OS 专用 job」的结构，避免为每个操作系统分别编译同一批产物。
主要能力与设计思路
- 单 runner 交叉构建：在 ubuntu-22.04 上一次性产出 Linux 目录树、macOS 两种架构与 Windows 包。
- 精简平台专用 job：
build-desktop-packages在 Linux 上交叉构建，wrap-mac-dmg在 macos-14 上通过needs依赖前者，只解包 macOS 归档并调用仅随 macOS 提供的映像工具包装成磁盘映像，不做任何编译，每个架构约一两分钟。 - 明确 job 拆分理由：把原因写在 workflow 文件顶部，防止后来者将其「简化」回 OS 矩阵，重新引入启动被拦截的对话框。
磁盘映像的必要性说明
打包器的 macOS 输出是普通归档。资料记录称，在 macOS 15 上，从被隔离的归档中解压出的应用会比通过挂载磁盘映像传播的同一应用受到更严格处理：归档路径会出现「developer cannot be verified」硬性拦截且没有右键打开的绕过方式，而磁盘映像路径只出现常规首次启动提示。同一应用、同一签名，因传播方式不同而隔离处理不同，因此需要包装步骤。
产物交接
两个 job 仅通过产物存储共享数据：job 1 用 actions/upload-artifact@v4 上传 desktop-mac-zips，job 2 用 actions/download-artifact@v4 下载同名产物。上传名称应按内容命名而非按 job 命名，使第二个 job 读起来像是在消费一个具名产物。
注意事项
- 外部调用的打包器不会触发 Gradle 任务依赖；通过
dependsOn接入打包任务的原生切片暂存不会在该路径运行，仍会打包成功但安装包缺少原生库，需要显式 workflow 步骤在打包器之前执行。许可证清单由其插件任务生成到源码树，配置生成也必须在打包器之前运行，同样需要显式步骤。 - 配置应在单独步骤生成静态文件，避免打包器读取会因构建工具标准输出而损坏的流。
- 打包器若在多次调用间清空输出目录，会把先前暂存内容清掉；应暂存到自有目录并在最后复制进去。
- 每次调用需限制构建平台，否则可能以中间产物身份重入其他平台流水线，因非预期产物导致整个构建失败。
- 遍历下载归档时应从文件名推导架构，无法推导则失败退出；示例：
arch="$(basename "$zip" | sed -nE 's/.*-mac-([a-z0-9]+)\.zip/\1/p')"，并配合[[ -z "$arch" ]] && { echo "Cannot infer arch from $zip" >&2; exit 1; }。 - 每个多行 shell 步骤使用
set -euo pipefail与shopt -s nullglob，避免空匹配循环与管道中途失败不可见的问题。 - 版本号应从定义它的文件读取，例如：
run: echo "version=$(grep '^version-name' gradle/libs.versions.toml | head -1 | cut -d'"' -f2)" >> "$GITHUB_OUTPUT"。 - 只安装 runner 实际需要的工具，并及时清理随方案变更而不再需要的工具链步骤。
验证方式
- 将
ls -lh输出目录作为独立步骤，便于失败日志排查。 - 在后续步骤依赖的产物应存在的位置，用
::error::注解断言，而不是等到消费步骤失败。 - 在从未构建过该应用的机器上确认发布体验，因为上述隔离行为在本地构建产物的主机上不可见。
限制
资料未提供该技能的具体运行环境要求、安装命令、支持的打包器名称与版本、收费信息或效果保证；以上内容暂未提供。