先纠正一个前提：证书不是带 App 老号的核心资产
很多买家把「证书」当成带 App 账号的主要价值，这个排序是反的。开发者后台里的证书只是公钥侧的记录，能签名的前提是私钥，而私钥通常只存在当初创建证书的那台 Mac 或 CI 里。后台能看到证书，不等于你能用它签名。反过来，证书丢了、过期了、被撤销了，都可以在账号内重新签发，已上架的 App 不会因此下架。真正换不掉的是 Bundle ID 和 App Store Connect 里的应用记录：Bundle ID 一旦用于创建应用记录就不能再改，评分、评论、内购商品、订阅组和用户的更新通道都挂在它上面。所以核对顺序应是应用记录和 Bundle ID 在前，证书在后。
Bundle ID 要查的不只是字符串，还有它开了哪些能力
在 Certificates, Identifiers & Profiles 的 Identifiers 里逐个打开目标 Bundle ID，记录三类信息。第一，是显式 ID 还是通配符 ID，通配符无法支持推送、内购等能力。第二，Capabilities 勾选了哪些，例如 Push Notifications、Sign in with Apple、Associated Domains、App Groups、iCloud。第三，这些能力背后依赖的外部资源是否在你手里。Associated Domains 要求你能控制对应域名上的校验文件，Sign in with Apple 和推送还会关联 Key 或 Services ID。如果能力依赖的域名、服务端或第三方推送平台仍在卖家或前团队手里，包名虽然到了你的账号，功能却可能起不来。
应用记录的状态决定你买到的是「能更新的 App」还是「一个空壳包名」
让卖家提供 App Store Connect 的应用列表和单个 App 的版本页面，重点看四项：当前版本状态是在售、已下架还是被移除；是否存在被拒或审核中的版本；内购商品和订阅是否仍在「已批准」状态；应用的主要语言、分类和隐私问卷是否完整。状态是在售且最近有过正常更新，说明这个包名仍然可用。已下架或长期没有更新的记录，要确认原因是主动下架、证书与协议问题，还是审核层面的处理，不要只听口头说明。是否有未结的审核问题，以平台后台当时的显示为准。
推送密钥、APNs 与服务端配置：能重建的和不能重建的要分开
APNs 认证密钥（.p8）只能在创建时下载一次，后台只保留记录，无法再次取回。如果现有服务端正在用这把密钥，而你没有拿到文件，后果是需要新建一把并改服务端配置，而不是「原样接手」。同理，Distribution 证书的 .p12、Sign in with Apple 的私钥文件都属于「后台看得到、手里未必有」的对象。下单前把这类对象列成两栏：账号内可重新生成的，和依赖卖家保管文件的。后一栏越长，越要在交付前明确哪些文件要给、哪些由你重建、重建期间线上功能是否受影响。
团队与协议状态会影响你能不能真正操作这个 App
即使 Bundle ID 和应用记录都在，也要确认谁是 Account Holder、你拿到的角色是否能管理 App 与协议。App Store Connect 的「协议、税务和银行业务」里，付费 App 协议未生效时，内购和付费功能无法正常运作；免费无内购的 App 则不受此限。这块的所有权和交接方式，本站另有文章专门讨论，这里只提醒一点：带 App 的账号要结合 App 的商业模式来核对，免费工具类和有订阅的应用，需要确认的协议与收款项完全不同。
哪些情况不必带 App，换干净老号更稳
如果你的目的只是拥有一个年限较长的账号，准备发布新 App，那么带一个别人的 Bundle ID 和历史记录没有必要，还会引入包名命名、历史评论和审核记录等不属于你的变量。只有以下情形才值得选带 App：需要延续一个仍在售的包名及其用户；内购或订阅已有存量用户；业务上必须保留现有评分与评论。停止下单的信号也很明确：卖家无法展示应用记录的后台页面，说不清 Bundle ID 的能力依赖，或交付范围只给账号登录信息而不说明应用记录与密钥文件。若 App 已存在于另一个账号，也可以评估用官方 App Transfer 迁移，但转移条件以 Apple 当时的页面为准，不要默认任何 App 都满足。