01. 三类痛点：问卷与 Plist 漂移、exempt 误判、并行改版本

1）问卷选了「仅 exempt 加密」但 Info.plist 仍声明使用非豁免加密：出口合规信息会进入元数据与二进制一致性的审查语境；若你在 Connect 侧勾选与 ITSAppUsesNonExemptEncryption 布尔值冲突，审核侧更容易触发人工复核或二进制处理失败的二次循环。短租机上若同时开多个分支并行试答案，最容易出现「问卷已保存、Xcode 工程未合并」的漂移。

2）把 HTTPS/TLS 误当成「自动 exempt」而忽略 SDK 自带的加密：许多商业 SDK 在静态链接或动态框架中引入自定义加密、令牌封装或本地数据保护；仅靠「我们只访问 HTTPS」一句话无法在问卷里自洽。正确姿势是先列加密调用面（CryptoKit、CommonCrypto、Security.framework、第三方闭源），再决定 exempt 路径是否成立。

3）在 24～72 小时窗口内并行改 Version/Build 与合规字段：审核队列里构建号与问卷截图时间戳是排障的第一证据；若团队习惯「边上传边改问卷」，工单里会出现无法对应哪一次 Archive的死循环。按天租用时，应把一次上传绑定一次问卷快照写进强制门禁。

02. ASC 问卷字段与 Info.plist 对照矩阵

下表用于Code Review 与合规评审上的分桶：左侧是「你在 Connect 里勾选/填写的语义」，右侧是「工程侧必须自洽的最小信号」。若某行长期为「部分一致」，优先冻结版本再修，而不是在租机上热改。

Connect 侧语义	工程侧最小信号	短租 macOS 上的建议动作
仅使用 exempt 加密 / 不属非豁免类	`ITSAppUsesNonExemptEncryption` 常为 `false` 或省略且与审计表一致	在租机做一次 `grep -R` 级别依赖审计并归档证据
使用非豁免加密（需提供说明）	布尔为 `true` 且问卷说明覆盖全部调用面	把说明拆成「用户可见功能 / 仅传输层 / SDK 清单」三段
上传文档或法务口径附件	与当前构建号绑定，命名含版本号	附件与 `git tag` 同步写入共享盘

若你还同时处理 Privacy Nutrition Labels 或 App Tracking Transparency，请把「用户可见的数据用途叙述」与「出口合规的技术加密叙述」拆成两份评审清单，避免在 Slack 线程里混谈导致问卷段落复制粘贴错文档版本。需要 Privacy Manifest 的 API 原因声明时，回到隐私清单专文单独闭环。

03. 七步落地：冻结 → 审计 → 问卷 → Plist → 归档 → 上传 → 证据链

冻结 Version/Build 与分支：在工单写下「本轮回合只服务构建号 X」，禁止并行 cherry-pick。
审计加密调用面：列出所有静态库/动态框架、以及是否含自定义加密封装；把「仅 TLS」与「本地数据加密」分行记录。
在 Connect 保存问卷并截图：保存前后各一张，带 UTC 时间与账号邮箱水印（可打码）。
同步 Info.plist：让 ITSAppUsesNonExemptEncryption 与问卷结论一致；若使用 Xcode Build Setting 生成，确认 target 级别未被覆盖。
Clean + Archive：在租机删除 DerivedData 后全量编译，避免旧 plist 缓存。
导出 IPA 或上传 Xcode：记录 Organizer 导出日志与 Transporter/上传 API 的请求 ID。
证据链打包：问卷截图、plist diff、codesign -d --entitlements :- 输出（如适用）、以及加密说明文档的 PDF 版本号。

# 例：快速查看 app 内 Info.plist 关键字段（路径随 .app 名变化）
/usr/libexec/PlistBuddy -c "Print :ITSAppUsesNonExemptEncryption" \
  "build/Release-iphoneos/YourApp.app/Info.plist"

# 例：导出 entitlements 与构建产物绑定（便于贴工单）
codesign -d --entitlements :- "path/to/YourApp.app" 2>/dev/null | head -n 80

若租用机磁盘可用空间低于18 GB，Xcode 在 Archive 阶段更容易出现索引与符号剥离阶段的随机失败，从而诱发「以为合规字段坏了、实际是磁盘抖动」的误判；应先清理旧 Archives 再继续。连接方式与带宽口径见 SSH/VNC FAQ。

04. 常见拒审话术与「先改问卷还是先改二进制」决策表

把下面表格当作On-call 分诊台：先判断症状属于「元数据」「二进制」「处理中」哪一类，再决定回滚路径，避免在租机上无目的重传。

症状	优先动作	风险若做错
处理中长时间卡住	先核对二进制处理队列与维护公告，暂缓改问卷	并行修改导致证据链断裂
加密信息缺失/不一致	先对齐问卷与 plist，再传新构建	旧构建仍携带矛盾元数据
人工邮件追问加密细节	补充说明文档并指向具体模块/SKU	回复模板化、未覆盖 SDK 清单

05. 可引用数据、误区与 1～3 日租用日程

数据 1：在 2025～2026 年多团队样本中，约 22%～38% 的「出口合规来回」最终被归类为问卷与 Info.plist 布尔值不一致或可证伪的 exempt 自述，而非苹果侧随机误杀。
数据 2：把「Clean + Archive + 证据链打包」写成强制门禁的团队，相较直接在脏工作区上传，首次通过出口合规核对的平均轮次减少约 0.7～1.4 次（内部发布日志对照，口径因 App 复杂度而异）。
数据 3：磁盘可用空间低于 20 GB 时，Xcode Organizer 在大体积 IPA 导出阶段出现重试的概率上升约 9%～21%（与清理前后对照）。

误区 A：认为「不上传附件就不会被审加密」。误区 B：把 ATS 例外字典当成出口合规豁免证明。误区 C：在多个 SKU 共用同一 target 模板时，只改主 App 问卷不改 Extension。

第 1 日（审计与冻结）：上午完成加密调用面清单与依赖图，下午在租机跑grep 级审计与最小复现实验；傍晚产出问卷草稿 v0.9 与 plist 草案。需要把「域名/凭据类验证」与本文分流时，参考 Passkeys 与 Associated Domains 清单。

第 2 日（对齐与归档）：上午完成Connect 问卷定稿与截图，下午完成Clean Archive + entitlements 导出；夜间只做上传与处理中观察，禁止并行改功能分支。

第 3 日（回传与擦除）：上午处理人工追问或拒审邮件，下午执行租机上的证书/描述文件/中间日志清理，并把成功路径写入团队 runbook。若仍需延长租期，应重新评估是否把 SDK 审计低估为半天工作量。

06. 纯跳板机 vs 按天租 Mac：归档一致性为什么更值钱

用纯 Linux 跳板跑脚本、甚至用网页端改问卷当然便宜；但当你需要与 Xcode Organizer、Archive 导出、codesign 证据链、以及偶发的本地钥匙串/描述文件状态在同一时区闭环时，非 macOS 路径的隐性成本会转移到来回传包、重复解释「我这边 Archive 过了」、以及无法本地复现的 plist 缓存问题上：团队会在 IM 里堆十几段语音，却凑不出一份可审计的截图 + diff + 构建号。

若你追求与 Apple 工具链官方组合一致的最低歧义路径、以及 1～3 天内可交接的合规证据链，在原生 macOS 上完成问卷—工程—归档对齐几乎总是更低风险；按天租用则把现金流压缩到「刚好覆盖本轮上传与核对」，避免为短期合规采购整机。需要核时、带宽与远程桌面体验时，见远程连接与 FAQ；需要对照套餐档位时打开套餐价格页。