证书和描述文件不决定 App 归属
很多买家把「证书和描述文件齐不齐」当成验收带 App 账号的第一项，这个顺序偏了。App 属于哪个账号，由 App Store Connect 里的 App 记录、Bundle ID 和 Team ID 决定，不由本地签名文件决定。证书和描述文件是签名工具，丢了可以重建，拿到了也不代表你拥有这个 App。所以下单前应先确认账号下确实存在该 App 记录，再去看签名材料。
先核 App 记录、Bundle ID 与 Team ID
要卖家提供或当面演示的是几项可对照的信息：App Store Connect 中该 App 的名称、Bundle ID、当前版本状态（在售、被下架还是已移除），以及开发者后台显示的 Team ID 和账号类型（个人或组织）。Bundle ID 必须与线上 App 完全一致，Team ID 必须是这个账号自己的。如果 App 其实是从别的账号转移过来的，要问清转移是否已完成、记录里是否还残留待处理状态。具体页面字段和入口以苹果当时的后台为准。
分发证书：关键是能否重建，而不是私钥在不在
Apple Distribution 证书需要配套私钥（通常导出为 .p12）才能在某台 Mac 上签名。原持有人的私钥不一定会交给你，这本身不是风险点：证书丢失或不可用时，可以在账号内吊销并重新创建，已经在 App Store 上架的版本不会因此消失。真正要问的是三件事：账号内现有证书是谁的、有没有 CI 或外包团队仍在用、吊销后会不会影响他们正在跑的构建。证书数量有上限，具体以平台页面为准，所以别让卖家为了「交付整齐」随意批量吊销。
描述文件可以重新生成，但要核对绑定的能力
描述文件由 App ID、证书和设备（开发或 Ad Hoc 时）组合生成，过期或失效后在后台重新生成即可。比文件本身更重要的是 App ID 上启用了哪些 Capabilities，例如推送通知、Sign in with Apple、关联域名、App Groups、应用内购买。这些配置一旦缺失，新构建会在签名或运行时出问题。让卖家截图或导出 App ID 的能力清单，与线上 App 实际用到的功能逐项对上。
容易漏掉的不在证书里：推送密钥与第三方凭据
带 App 账号最常见的交接事故，是推送突然失效。服务端用的 APNs 认证密钥（.p8）只在创建时可下载一次，如果后台服务还绑着旧密钥，而你或卖家把它吊销了，推送会立即中断。同类还有 Sign in with Apple 所用密钥、应用内购买的服务器通知配置，以及第三方 SDK 里绑定了 Team ID 或 Bundle ID 的凭据。下单前要问清：这些东西现在由谁的服务器在用，交接后是否继续使用，由谁负责切换。
下单前的核对清单与停止条件
建议按这个顺序核：账号类型与 Team ID，App 记录与 Bundle ID，线上版本状态，现有证书与使用方，App ID 能力清单，推送与登录相关密钥的使用方，协议与银行税务状态是否正常。出现以下情况应暂停下单：卖家无法展示 App 记录；Bundle ID 或 Team ID 对不上；App 近期有被拒、下架或申诉未结的记录却不说明；声称「交证书就等于交 App」。账号本身的会员状态、费用和审核情况会随平台调整，一律以苹果当时的页面为准。
常见问题
卖家不给 .p12 私钥，账号还能正常更新 App 吗？
通常可以。只要账号权限正常，可以在后台新建分发证书并重新生成描述文件，用新证书签名发布更新。前提是确认没有其他构建系统依赖旧证书。
证书吊销后，已上架的 App 会受影响吗？
已经在 App Store 上架的版本一般不会因此下架。受影响的是依赖该证书的新构建和自动化流程，企业内部分发类证书的情况不同，需另行核对。