先分清买的是账号，还是账号加这个 App
带 App 的老号有两种常见需求。一种是要这个应用本身，包括用户、评分和更新权；另一种只是想要一个有历史记录的账号，应用只是顺带存在。两者的核对重点完全不同。前者要把应用当资产验收，后者要确认应用不会成为负担。下单前先让卖方列出账号内每个应用的包名、当前状态（已发布、测试中、草稿、已下架）、最近一次更新时间和商店可见地区。包名在应用创建后无法更换，所以包名对不上你的用途，就不要往下谈。
第一层资料：账号身份和登录控制权
这一层决定你拿到手之后能不能稳定使用。需要核对的字段包括：账号类型（个人或组织）、注册国家或地区、开发者账号 ID、当前验证状态、控制台里的所有者权限、登录用的 Google 账号及其恢复邮箱和手机号、两步验证绑定在哪台设备上。常见隐患是登录凭据已经给了，但恢复方式仍指向卖方的邮箱或号码。这种情况下账号表面可用，实际控制权并没有完整转移。要求卖方在约定节点同步更换恢复信息，并在你自己的设备上完成一次完整登录。
第二层资料：签名与上传密钥决定你能不能继续更新
能登录控制台，不等于能给原包发布更新。已启用 Play 应用签名的应用，Google 保管应用签名密钥，开发者持有上传密钥。上传密钥丢失时，通常可以通过 Play Console 的支持流程申请重置，但需要时间。未启用的老应用，则必须拿到原始 keystore 文件、别名和密码，缺任何一项都可能导致无法更新同一个包。下单前让卖方说明每个应用是否已启用 Play 应用签名，并要求交接时提供上传密钥或 keystore。这一项缺失，应用的实际价值要大幅打折。
第三层资料：源码、后端与关联服务
应用能上架不代表你能维护它。需要确认的包括：源码仓库及其访问权限、构建配置、依赖的后端接口和服务器、Firebase 项目、AdMob 或其他广告账号、第三方登录和推送的密钥、Google Cloud 里的服务账号与 API 访问授权、隐私政策和数据安全表单所指向的域名与联系邮箱。这些服务经常登记在卖方的另一个账号下，账号交了，应用却因为后端或密钥停用而失效。清单里每一项都应写明由谁持有、是否一并转移、转移后原持有人是否保留访问权。
交接顺序：先核对，再换控制权，最后验证能发布
比较稳妥的顺序是五步。第一步，卖方在控制台展示账号类型、应用列表和状态，你核对后再推进。第二步，交付签名材料和源码，你本地验证能否构建出与线上包名一致的版本。第三步，按双方约定的方式转移控制权，并更换登录凭据、恢复信息和两步验证。第四步，移除不再需要的旧用户和旧服务授权。第五步，由你自己的账号上传一个草稿版本或内部测试版本，确认权限完整。开发者名称、联系资料等改动可能触发重新验证，是否要改、何时改，以平台当时页面和要求为准，不要在交接中途随意变更。尾款应放在第五步确认之后。
出现这些情况就该暂停或换成无 App 的号
有几类情况建议停止或改买无应用账号。应用或账号收到过政策警告、受限或下架记录，且卖方无法说明原因和处理结果。卖方拿不出签名密钥，又不能确认启用了 Play 应用签名。应用依赖的后端和密钥不在交接范围内。应用内容、类目或目标地区与你的实际用途冲突。你只需要账号主体和历史，不打算维护这个应用。反过来，如果资料清单能逐项对上、签名和源码可验证、更新权在你手里，带 App 的老号才算得上一个完整交付。