先分清：买的是整个账号，还是账号里的那个 App
带应用的老号有两种完全不同的交付方式。一种是整体交接账号，应用留在原账号里，你接手的是账号本身；另一种是通过 App Store Connect 的应用转移（App Transfer），把 App 从卖方账号转到你已有的开发者账号。前者的风险集中在账号主体和登录控制权，后者的风险集中在转移的前置条件和应用所用的能力是否受限。下单前先说清楚你要哪一种，因为两者要核对的资料、交接顺序和出问题后的补救方式都不同。如果你已经有符合条件的开发者账号，只想要某个 App，通常转移更干净；如果你要的是账号的年限、主体类型或国家属性，才需要整体交接。
应用状态要在 App Store Connect 里逐项看到，而不是听描述
让卖方提供后台截图或在你在场时共同查看，至少核对这些字段：应用当前状态（在售、已下架、被移除、审核中）、Bundle ID、最新在售版本号、应用所属的销售国家和地区、是否有内购项目或自动续期订阅、历史版本的审核记录里有没有被拒或警告。再看应用启用了哪些能力，例如推送通知、Sign in with Apple、iCloud、关联域名、App Groups。这些能力与证书、标识符绑定，转移或换主体后往往需要重新配置，部分能力在应用转移时还有限制。具体前置条件和限制清单以 Apple 当时的官方文档为准，不要凭记忆判断。已下架或长期未更新的应用，要确认原因，是主动下架还是因违规被处理。
账号里有 App，不等于你拥有它的源码和素材
开发者账号只证明谁在 App Store 上架了这个应用，不证明谁拥有代码。交接前要明确三件事：源码和构建脚本是否一并交付，交付形式是什么（仓库移交还是压缩包）；第三方 SDK、字体、音频、图标等素材的授权是否随应用转让；后端服务、API 域名、云账号和统计、崩溃收集等服务的账号归谁。很多带应用的老号买到手后，应用能在线但无法更新，原因就是只拿到了账号，没有可编译的源码，或后端仍在卖方名下。如果没有源码，就应在价格和用途上把它当成一个「只保留上架记录」的资产，而不是可持续运营的产品。
登录凭据与主体资料：谁控制 Apple ID，谁是账号持有人
整体交接时，核对账号持有人（Account Holder）对应的 Apple ID、绑定的邮箱和手机号、双重验证接收设备是否可以在交接中变更并由你掌握。个人号看持有人的实名信息与账号注册国家是否一致；组织号则要看法律主体名称、D-U-N-S 编号、网站和联系人是否仍有效。账号持有人的变更、主体信息的修改，应走 Apple 官方支持流程，并按平台当时要求提交材料。任何要求你使用他人名义的验证信息、伪造文件，或让卖方长期保留双重验证控制权的做法，都不应接受，这类账号之后被复核时很容易整体失效。
一个合理的交接顺序，以及每步的验收点
较稳妥的顺序是：先在后台确认应用状态与能力清单并留存记录；再确认源码、素材和后端权属并完成交付；然后处理登录与联系方式的变更，确保你是唯一能通过双重验证的一方；最后才结清尾款。如果走应用转移，则由卖方在后台发起、你的账号接受，接收后再重新核对 Bundle ID、内购项目、证书和描述文件是否仍可用，并用测试构建走一遍提交流程。每一步的验收点都应是你能自己操作出来的结果，比如自己登录、自己新建构建、自己编辑商店信息，而不是卖方口头保证。
出现这些情况，先暂停交易
遇到下面几类情况，建议暂停并重新评估：卖方无法在后台展示应用状态，或只给静态截图；应用有过被拒或被移除记录但拿不出说明；源码、后端和素材权属说不清；双重验证设备始终不愿交出；账号主体信息与实际销售国家、收款地区不匹配；应用依赖的能力在转移后会失效且没有替代方案。这些问题多数不会在交接后自然消失。另外，账号状态、会员有效期和审核结果会随平台政策变化，任何评估都以交接当天你在后台看到的状态为准。
常见问题
带应用的老号和空账号，价格差异应该怎么判断？
看应用能否被你继续更新和运营，而不是看有没有上架记录。有源码、后端可控、状态正常的应用有实际价值；只有上架记录、无法更新的应用，价值接近一个有历史的空账号。
已经有开发者账号，还需要买带应用的老号吗？
如果只是想要某个应用，优先考虑应用转移到自己的账号，前提是满足 Apple 当时的转移条件。只有在需要账号年限、特定国家或主体类型时，整体购买才有意义。