首屏摘要：签名正确但传输后坏掉的五条典型路径
远程 Mac 上常已跑通 codesign、notarytool、stapler，问题多在之后：ZIP/SFTP 默认、rsync 丢权限、upload-artifact 对 symlink 的处理等，把 .app 从 bundle 变成「展平树」，codesign --verify 随即失败。本文讲工程化交付：用同平台 rsync、tar 归档与仅在 macOS 上 staple/终验对齐签名语义与搬运语义。
与完整性的关系：codesign 验签名图，SHA256 验字节；站内《传输完整性》讲闸门。请在每一跳后加 codesign --verify --deep --strict，不要等哈希对上了才发现签名已碎。原子发布仍适用：只写 releases/<build_id>/，校验后切 current（《原子发布》）。带宽瓶颈见《大文件上传吞吐》。
痛点拆解：为什么 symlink、扩展属性与权限位会悄悄杀死签名
痛点 1：把 bundle 当普通目录。.app 依赖 symlink 与可执行位；随意 ZIP/网盘往返常丢元数据。正式路径须写死 zip/unzip 参数并在目标机 verify。
痛点 2：macOS runner → Linux → 回 Mac。根因多为 symlink 展开与权限丢失。要么目录级不离开 macOS，要么离站前 tar.gz，回 Mac 立刻 verify。
痛点 3：--inplace 与发布语义。in-place 可能暴露半套目录；应用新前缀完整写入再切换，partial 结束须原子改名（见《原子发布》）。
痛点 4：staple 后二次改镜像。DMG 公证后若再压缩或重写边缘，票据可能与最终字节不一致；对外文件名与 staple 时刻应写入工单并冻结。
痛点 5：只源站 verify 不到岸 verify。在消费构建的下一台 Mac 必须重复严格验证，并保留命令与退出码日志备查。
决策矩阵：同平台 rsync、跨平台 tar 与「Mac 内闭环」怎么选
评审时固定字段：构建号、签名身份、submission id、分发格式、传输工具、每跳 verify、SHA256 是否绑定。
| 场景 | 优先假设 | 推荐路径 | 与站内文档 |
|---|---|---|---|
| 远程 Mac → 另一台 Mac，内网低时延 | 元数据可完整保留 | 显式 rsync 保留权限与扩展属性；禁止多任务写同一前缀 | 并发 SFTP、原子发布 |
| 远程 Mac → Linux runner → 回到 Mac | symlink 与权限易丢 | 在 Mac 侧 tar.gz；Linux 只搬运单文件；回 Mac 后立刻 verify | 传输完整性 |
| 对外给测试的 DMG | 镜像层签名与票据绑定 | 固定打包脚本；staple 后冻结文件名；SHA256 登记 | 完整性闸门 |
| 仅内部 CI 缓存 | 可重建 | 可接受未公证中间态，但要在晋级发布前重新跑完整签名链 | CI 凭据文 |
| 大体积 app 与窄带宽 | 时间长、中断多 | 并行/分片策略前先 tar 单文件；结合 partial 与原子切换 | 大文件上传吞吐 |
核心：签名依赖 macOS 文件语义；跨平台须用能保留语义的归档。
实操步骤：从打包、SFTP/rsync 上传到 verify 与暂存区（How-to）
教学骨架；生产须对齐《CI/CD 凭据》与 releases/<build_id>/。
# 步骤 1：在构建 Mac 上将 .app 打成 tar.gz（保留 symlink）
cd /path/to/output
COPYFILE_DISABLE=1 tar -czvf MyApp_build123.tar.gz MyApp.app
# 步骤 2：严格验证仍在构建机上执行一次
codesign --verify --deep --strict --verbose=2 MyApp.app
# 步骤 3：经 SFTP/rsync 推到远程 Mac 的暂存前缀（示例 rsync）
rsync -av MyApp_build123.tar.gz [email protected]:uploads/staging/build-123/
# 步骤 4：在远程 Mac 解包到同 build 前缀内新目录
ssh [email protected] 'cd uploads/staging/build-123 && tar -xzvf MyApp_build123.tar.gz'
# 步骤 5：到岸后再 verify（关键）
ssh [email protected] 'codesign --verify --deep --strict uploads/staging/build-123/MyApp.app'
# 步骤 6：若本轮包含 staple 后的 DMG，再对 DMG 路径执行 stapler validate / spctl 评估
# 步骤 7：仅校验通过后，才允许晋级到 current 或对外下载区（参见《原子发布》）
# 步骤 8：把命令、退出码、构建号写入 CI 摘要行，便于与 SHA256 清单对齐
交互式 SFTP 务必将保留权限/递归写入 SOP，避免手滑毁内测窗口。
可引用数据与检查清单字段（写进发布工单）
工单建议字段：构建号、Git SHA、Xcode/macOS 小版本、签名身份摘要、submission id、对外文件名、staple 状态、源站/到岸 verify 退出码、传输工具版本、SHA256。notarization 繁忙时轮询可达数十分钟，应纳入流水线预算；磁盘长期低于约 120GB 可用易诱发 Archive 异常（参见吞吐文）。签名产物目录建议与普通素材分账号隔离。
FAQ、站内互链与为何考虑托管远程 Mac
能否只靠 SHA256 证明签名没问题？
不能。SHA256 只能证明字节一致；若一致但仍 verify 失败，说明你在上游记录的「应然字节」本身已不含有效签名图。两条检查都要：先 verify，再登记哈希。
Linux 上能跑 codesign 吗？
工程上不应把 Linux 当作 macOS 签名链的最终裁判。可以在 Linux 上搬运 tarball，但严格验证应在 Mac 上完成。
SFTP 是否一定比 rsync 差？
不一定。无人值守场景下二者都能写好；差的是是否显式规定参数与验证步骤。rsync 在目录增量上更强，SFTP 在简单 put/get 上更直观。
总结：签名与公证只解决一半；另一半是归档/传输保留 bundle 语义，每跳 verify，并联 SHA256 与原子发布。
局限：多入口自建成本高；SFTPMAC 托管远程 Mac收敛构建、加密入口与会话策略，减少「解压后签名坏」类排障时间。
了解 SFTPMAC 套餐与节点区域，统一远程 Mac 承载签名与分发。