TG咨询云手机更换实例或迁移存储后，应用能打开不等于数据完整。要做好云手机应用数据迁移前后的完整性校验，应先记录迁移前的状态，再逐项核对迁移后的文件、数据库和实际功能。不同云手机平台提供的备份与恢复能力不同，以下步骤可按平台权限调整。
1. 先界定要迁移和核验的数据
列清单时，把应用数据分成几类：账号与配置、业务记录、图片和文档等附件，以及本地缓存。缓存通常可以重新生成，不应和用户数据混为一谈。记录应用名称、包名、版本号、账号标识和迁移时间；若应用提供官方导出功能，优先确认导出范围和恢复方式。
注意，Android 应用的私有目录通常受系统沙箱保护，不能假设可以直接复制。迁移前先确认平台是否支持应用级备份、实例克隆，或由应用内导入导出完成数据转移。
2. 迁移前建立可比较的基线
- 在源云手机中打开应用，记录关键页面上的条目数量、最近记录和重要设置。
- 对可导出的文件保存清单，记录文件名、大小、格式和数量；重要文件可计算 SHA-256 校验和。
- 若应用允许导出 CSV、JSON 或 SQLite 数据库，保留原始导出文件，并注明生成时间及对应账号。
- 截图或记录无法导出的关键状态，但不要把截图当成数据备份。
校验和只能证明文件字节是否一致，不能单独证明应用能够正确读取文件。SQLite 数据库若采用 WAL 日志模式，数据库文件与日志文件可能共同包含尚未合并的数据；应使用应用或平台支持的备份方式，避免只复制单个文件。
3. 按平台支持的方式执行迁移
优先采用云手机服务提供的迁移或备份恢复功能，其次使用应用自身的导出与导入；只有在平台明确支持时，才考虑文件级复制。迁移过程中记录源实例、目标实例、操作时间、选用方式和结果。重要数据先保留一份可恢复的源备份，确认目标数据可用后再清理旧实例。
4. 迁移后做三层核对
文件层
重新导出或列出目标端文件，核对数量、大小和格式。对未发生转换的文件逐个比较 SHA-256；如果服务会压缩图片、重编码音视频或重新生成缩略图，哈希不同不一定代表内容丢失，应进一步检查文件能否打开及内容是否完整。
记录层与应用层
对比迁移前后可见记录数量、日期范围、重要字段和附件关联。打开几条较早、较新及带附件的记录，检查详情是否完整。随后退出并重新登录应用，再次查看关键页面，确认数据不是仅留在临时缓存中。云手机应用数据迁移前后的完整性校验应同时覆盖这些层面，而非只检查文件是否存在。
5. 发现差异时定位原因并留痕
- 先确认源端和目标端使用的是同一账号、应用版本及数据范围，排除筛选条件不同。
- 检查应用是否仍在同步、是否需要重新授权，以及目标端是否缺少附件或数据库日志。
- 把差异分为缺失、内容不一致、格式变化和暂未同步，保存文件清单、截图与操作时间。
- 对无法解释的缺失，暂停删除源数据；重新导出或恢复前先核对备份范围，避免重复导入造成重复记录。
验收标准应贴合应用用途：文件型数据可要求清单和校验和匹配；会在目标端重新生成的数据，则以记录可读取、关键字段一致、附件可正常打开为准。完成核对后，保存迁移记录，便于后续追查。
常见问题
只比较文件数量够吗？
不够。数量相同仍可能有文件内容损坏或附件对应错误，应结合大小、校验和及实际打开检查。
SHA-256 不一致就说明迁移失败吗？
不一定。若文件经过压缩、转码或重新生成，字节会变化；需要判断内容是否符合预期。
应用能启动，是否可以结束验收？
不能。还应核对关键记录、附件和设置，并重新进入应用确认数据仍可读取。完整的云手机应用数据迁移前后的完整性校验，最终要以业务数据可用且差异有记录为准。