三者处理方式不同：会员要核对，成员要清理，证书不必接旧的
这三项经常被写进同一句「全套交接」，但性质完全不同。会员状态是账号当前的事实，只能核对，不能「交付」。团队成员是权限面，交接后应该清理到只剩你认识的人。证书是签名凭据，Apple 只保存证书本身，不保存私钥，所以旧证书对买家的价值很有限，多数情况下交接后重新生成更稳妥。下单前把这三项分开写进验收清单，比笼统要求「全部交齐」更有用。
会员状态：看四个字段，而不是只看能不能登录
能登录 developer.apple.com 不等于会员有效。至少核对：会员是否处于有效期内、到期日、自动续费开关、账号类型（个人或组织）以及 Team ID。会员一旦过期，已上架的 App 可能被下架，也无法再提交新构建，具体规则以 Apple 当时的页面和协议为准。另外要确认 Account Holder 是谁，因为协议签署、续费和部分设置只有 Account Holder 能操作。还要留意账号的转让是否符合 Apple 当时的协议条款，这一点应在下单前向卖家问清楚，而不是交接后再处理。
团队成员：老号最常见的隐患是没人说得清谁还有权限
老号常留有前任员工、外包团队甚至已经离职的人。在 App Store Connect 的「用户和访问」里逐个核对：角色是 Admin、App Manager、Developer 还是只读角色，邮箱是否属于已知人员。Admin 及以上角色可以管理用户和证书，风险最高。交接前后都应移除无法解释的成员，并同步检查「集成」里的 App Store Connect API 密钥，这类密钥独立于登录密码，成员被移除后密钥仍可能有效，需要单独撤销并重建。账号绑定的 Apple 账户邮箱、手机号和双重验证受信任设备也要一并更换，否则原持有人仍可能拿到验证码。
证书：私钥在哪台电脑上，才决定旧证书有没有用
证书创建时的私钥保存在生成签名请求的那台 Mac 的钥匙串里，Apple 后台只能下载证书，下载不到私钥。所以卖家口头说「证书一起给你」，实际能用的只有导出的 .p12 文件，而 .p12 含私钥，经聊天工具传递本身就有泄露风险。更合理的做法是：不接收旧私钥，交接完成后由买家用自己的电脑生成新的 Distribution 证书和描述文件。旧证书如果占用名额，可以撤销，但撤销前要确认卖家的 CI、Ad Hoc 分发或仍在进行的构建是否还在使用。已经上架 App Store 的 App 通常不受证书撤销影响，但这个判断仍以你账号的实际情况为准。
带 App 的老号：证书之外还有几类更难重建的凭据
如果购买的是带已有 App 的账号，风险点不止证书。推送使用的 APNs 密钥（.p8）只能在创建时下载一次，丢失后只能重建，重建后服务端配置必须同步更新，否则推送中断。Sign in with Apple 密钥、关联域名、App Group、内购与订阅配置也都绑定在这个团队下。验收时让卖家说明每个 App 用了哪些能力，以及对应服务端是否由卖家掌握。凡是服务端掌握在卖家手里的，要么约定一并交付，要么约定买家重建并预留切换时间，不要等上架更新时才发现。
下单前的核对清单与停止条件
建议把验收项写成可检查的几行：Membership 页面显示有效且到期日明确；Account Holder 登录与双重验证已完成更换；成员列表只剩确认过的人；App Store Connect API 密钥已撤销或重建；证书由买家新建，不依赖旧私钥；带 App 时，各 App 的 Bundle ID 和所用能力清单已核对。出现以下情况建议暂停：卖家无法展示账号后台的真实状态；要求你先付款再说明成员和凭据情况；坚持让你接收来源不明的 .p12；成员列表里有无法解释的 Admin。具体费用、审核和账号规则会变化，以 Apple 当时的页面为准。