6.2 多平台构建与代码签名

6.2 多平台构建与代码签名

本节摘要：三平台构建的差异集中在产物形态、签名体系与构建环境（macOS 产物几乎必须在 mac 上构建）；代码签名的作用是让操作系统与用户能够验证应用来源，未签名的代价是 Windows 智能屏幕拦截与 macOS 门禁拒收。本节讲平台差异矩阵、签名信任链原理、CI 上的多平台构建组织方式，以及无签名阶段的过渡策略。

三平台差异矩阵

把"打出能用的包"这件事按平台拆开，差异一目了然：

最后一行是硬约束：macOS 的签名与公证工具链跑在 mac 系统上，跨平台构建 macOS 产物虽有路可走，但正道就是拿一台 mac（或 CI 的 mac 节点）来干。这也是为什么多数团队把多平台构建放进 CI 的多平台矩阵——三个平台各跑一个节点，产物汇合后统一发布。

签名到底在签什么

把信任链讲成一个故事。你的应用要进用户电脑，操作系统是门卫，门卫的问题是："你是谁？谁为你担保？"签名回答这个问题，链条有三环：

第一环，凭证。你向证书机构证明身份，机构发你签名凭证——这一环的本质是"花钱买的担保"，机构替你向全世界的操作系统背书。

第二环，签名动作。构建时用凭证对产物做签名，产物里嵌入了可验证的信息：谁签的、内容有没有被改。用户机器上的操作系统可以离线验证这环。

第三环，平台背书。Windows 的智能屏幕会查这份签名有没有积累信誉（新签名的应用起初信誉低，下载量上来后拦截提示会减弱）；macOS 更进一步，除了签名还要求公证——把产物提交给官方扫一遍，通过的产物带着票据，用户双击打开时门禁放行，否则用户面对的是"无法打开，因为无法验证开发者"甚至"移到废纸篓"的劝退界面。

# macOS 侧的签名与公证流水线（概念流）
构建产物（app 包）
  → codesign 用开发者证书签名（应用内每个框架都要签）
  → 构建 dmg 安装包，再对 dmg 签名
  → 提交公证（上传官方扫描）
  → 装订公证票据到产物
  → 用户双击：Gatekeeper 验证签名与票据 → 放行
​

不签名的真实代价不是理论上的：Windows 上用户下载后看到蓝色警告框，转化率断崖式下跌；macOS 上普通用户根本找不到"右键打开绕过"的隐藏路径，直接判死。企业内部分发可以靠组策略白名单缓解，面向公众分发，签名是必选项。

图：签名信任链与未签名代价

CI 上的多平台矩阵

签名与 mac 构建的硬约束，共同把多平台构建推向 CI 矩阵：一次提交触发三个平台的构建节点，各自跑单平台的打包与签名，产物统一归档发布。配置层面的要点有三：凭证不落仓库——签名密钥存 CI 的密钥管理，以环境变量注入，代码库里连影子都不能有；产物校验自动化——发布前自动验证签名有效性（打好的包在本机装一次、验一次），把"签名配置悄悄坏了"拦在发布前；矩阵差异显式化——三个平台的构建命令与参数差异写在配置的醒目处，避免"改了 Windows 忘了 mac"的经典事故。

过渡策略也值得说：预算或资质未就绪的阶段，宁可先只发签名完备的平台（比如先 mac 后 Windows），也不要全平台裸奔——第一印象的警告框是拿不回来的。 签名运维还有一件小事容易被忽略：证书有有效期，且续期往往需要走一遍身份核验流程，比想象中慢。把"证书到期前九十天"设成团队看板的常驻提醒，指定到人——证书过期当天才发现的团队，发布节奏要停摆一周起步，这对任何版本计划都是无妄之灾。企业内部分发场景可以用系统策略放行未签名应用过渡，但要在路线图上标明这是过渡。

关于三平台差异还有一个实操层面的补充：构建矩阵里最值得单独盯的是"产物冒烟"环节——每个平台打完包后，自动做一次安装、启动、执行一条核心命令、退出的最小验证。它拦住的是那些"构建成功但装不上""装上了但起不来"的平台特有损坏，比如 macOS 公证票据漏装订、Windows 安装器权限问题。这类问题在同事的开发机上永远复现不出来，只有冒烟机能替你站在用户的位置上验货。把冒烟脚本接进发布流水线的最后一步，三个平台各跑一遍，发布按钮才真正敢按下去——这五分钟的机器时间，是整个分发体系里性价比最高的投资之一。

冒烟环节还有一个常被问到的细节：验证用的机器环境要尽量"干净"——新建的虚拟机或容器环境，而不是开发者日用的机器。日用环境里装过的运行库、证书、白名单设置，都会悄悄掩盖真问题；干净的机器才最接近"第一次安装你软件的真实用户"。三个平台各备一台标准化的验证环境（可以是云端按小时租用的实例），每次发布跑一遍冒烟，成本几乎可以忽略，拦住的问题却往往是最贵的那类——毕竟用户替你发现安装损坏的那一刻，同时发现的还有"再也不想装了"的心情。

签名流水线的最后一块拼图是"发布日历"：把签名证书到期、平台政策变更（例如某平台开始强制要求新的公证格式）、以及自家发布节奏画在同一张时间线上，提前一个版本周期消化外部的硬变化。平台侧的签名要求几乎每年都有小调整，被动应对的团队总要停更一次才学会看公告，主动排期的团队则把这些变化变成了例行升级。

本节要点回顾

• 差异矩阵：产物形态、签名体系、构建环境三行差异，mac 构建基本必须在 mac；
• 信任三环：凭证担保、签名可验证、平台背书（Windows 信誉、macOS 公证）；
• 未签名代价：警告框劝退、门禁拒收、误报上升，公众分发必签；
• CI 纪律：密钥走密管、签名校验自动化、平台差异显式化；
• 过渡姿势：宁可分平台逐步上线签名完备版，不全平台裸奔。

包装好、签完名，下一节建立与用户的长期通道：自动更新——它既是体验工程，也是安全工程。