iPhone 数据恢复并不是一个单一动作。当前软件使用 Apple MobileBackup2 生成或读取电脑逻辑备份，再解析备份中的媒体文件、数据库、日志和缓存，并按证据强弱区分原文件、派生副本、缩略图与仅元数据。它不是 NAND 原始存储扫描，也不是 Full File System 提取。
先用一张图看懂完整链路
这条链路可以拆成五层：设备信任与通信、逻辑备份、文件清单映射、数据库与媒体解析、证据分级。每一层都可能决定某项内容最终是原文件、可用副本、只有缩略图，还是只剩一条记录。
第一层：设备连接与信任
iPhone 通过 USB 与 Windows 连接后，电脑需要 Apple 官方设备支持环境完成识别和配对。首次连接通常还要在手机上点击“信任”并输入设备密码。Apple 官方的 Windows 备份说明同样把连接、解锁和信任列为前置步骤。
软件在这一层只负责建立受信任的本地通信，不绕过设备密码，不越过 iOS 权限，也不通过刷机、越狱或恢复模式获取数据。连接失败时，问题通常发生在数据线、USB、Apple 设备服务、配对记录或其他手机管理软件占用。
第二层：MobileBackup2 逻辑备份
Apple 设备提供 com.apple.mobilebackup2 服务，用于电脑备份与恢复流程。软件通过这一逻辑备份通道，把系统允许进入备份的数据复制到用户选择的 Windows 工作目录，再对本地副本做分析。
“逻辑备份”与“读取整块闪存”有本质区别：
| 获取方式 | 能看到什么 | 当前产品是否属于 |
|---|---|---|
| MobileBackup2 逻辑备份 | iOS 允许进入电脑备份的文件、设置和数据库 | 是 |
| Full File System 提取 | 更大范围的系统和应用文件树，通常依赖额外条件 | 否 |
| NAND / 芯片级原始扫描 | 闪存物理页、未分配空间和底层控制器数据 | 否 |
因此，软件无法像传统电脑硬盘工具那样，直接扫描 iPhone 的 NAND 空闲空间并“雕刻”已经删除的原始 HEIC 或 MOV。iOS 的权限、数据保护和闪存管理机制决定了这条边界。
Apple 也明确说明，电脑备份包含设备的大部分数据和设置，但不包含所有内容。例如已经同步到 iCloud 的照片或信息、Apple Pay、Face ID/Touch ID 数据等可能不在电脑备份中；健康、钥匙串和部分记录则需要加密本地备份。当前软件只支持未加密的本地备份，所以“手机上曾经存在”并不等于“这次备份里一定存在”。
第三层：Manifest.db 把散列文件还原成路径
现代 iPhone 电脑备份中的大量文件以散列 ID 保存，而不是直接保留原始目录名。Manifest.db 记录了文件 ID、域、相对路径和属性，解析器据此判断某个散列文件原本属于相册、通讯录、短信、通话记录还是某个 App 容器。
可以把它理解为“备份文件的目录索引”：
文件 ID 指向备份目录中的实际对象。
Domain 区分相机胶卷、系统域和 App 域。
RelativePath 说明对象在原设备中的逻辑位置。
文件属性帮助判断类型、大小和备份状态。
如果备份没有完成收尾，Manifest.db 可能尚未生成或状态不完整。这也是扫描进度到 100% 后仍需要等待片刻的原因之一。只要完整清单已经存在，历史任务通常可以直接继续分析，不必再次复制整个手机。
第四层：照片数据库、媒体文件和缓存要分开看
照片恢复最容易被误解。照片资料库数据库（常见为 Photos.sqlite）保存资源之间的关系、UUID、文件名、时间、媒体类型和状态字段；真正的画面则位于 HEIC、JPEG、PNG、MOV 等媒体文件，或 UBF、缩略图、派生资源中。
一条数据库记录可能对应四种结果：
| 发现 | 能说明什么 | 不能说明什么 |
|---|---|---|
| 原始媒体文件仍在 | 可以尝试导出并验证完整性 | 不能仅凭路径断言从未删除 |
| 派生 JPEG / 视频帧仍在 | 可能保留较清晰画面或可识别内容 | 不等于原始 HEIC/MOV 的分辨率和元数据 |
| 缩略图仍在 | 至少曾生成过预览，有助于确认内容 | 不能放大成原图，也不代表原视频存在 |
| 只剩数据库记录 | 可提供 UUID、文件名、日期等线索 | 不能宣称已恢复原始照片或视频 |
此前验证中出现过的较高质量 JPEG 候选，本质上是删除后残留的派生资源，而不是从 NAND 空闲空间雕刻出的原图。对用户有价值的做法，是明确告诉他“找回了什么质量的文件”，而不是把所有可见画面都叫作原图。
为什么 SQLite、WAL 和残片还能留下线索
照片、联系人、短信和通话记录通常存放在 SQLite 数据库中。SQLite 数据库由固定大小的页面组成；删除一条记录后，页面可能进入空闲列表或仍包含未立即覆盖的字节。写前日志（WAL）还可能暂时保留尚未合并回主数据库的页面版本。
分析时需要在明确的工作副本上同时保留主数据库、-wal 和 -shm 上下文，然后做正常查询和受控残片检查。直接打开原备份并让工具修改数据库，可能破坏原始上下文，因此产品默认保持备份不变。
但“找到残片”不等于“恢复完整记录”。残片可能缺少列边界、编码、附件或时间字段，只能作为低等级证据；无法可靠确定的日期必须标为“日期未知”。
联系人、短信和通话记录为什么与照片不同
联系人和短信属于结构化数据。即使附件或头像已经不存在，数据库中仍可能保留姓名、号码、正文、发送方向、时间或会话关系。此类结果可以导出为可读信息，但必须区分：
现存记录：数据库当前结构可以正常引用。
有删除证据：删除标记、残片或上下文支持“曾被删除”的判断。
状态未知：找到了内容，但没有足够证据证明它当前存在或已经删除。
对于通话记录，Apple 官方说明未加密电脑备份与加密电脑备份包含的数据范围不同；当前仅支持未加密备份，因此具体字段是否出现取决于 iOS 版本、同步设置和备份内容，不能承诺每台设备都能得到相同结果。
一套更可靠的恢复证据等级
判断结果时，可以按以下顺序看证据：
文件可读性：能否完整打开、解码和播放。
来源路径：来自相机胶卷、系统派生目录、缩略图容器还是 App 缓存。
文件质量：格式、像素尺寸、码率、时长和元数据是否接近原文件。
数据库关联：UUID、文件名、资源关系和时间是否一致。
删除证据：是否有明确删除标记、残片上下文或前后状态对照。
只满足第五项、但没有实际媒体文件时，最多可以说“发现删除记录线索”；只看到缩略图时，可以说“找回预览图”；只有通过完整性验证的原位置媒体，才适合标为原文件候选。
这也是扫描数量不等于恢复成功数量的根本原因。想判断照片质量，可继续查看原图、派生图片与缩略图的区别。
删除后怎样做更有价值
如果照片或视频刚刚删除，先按低风险顺序处理：
检查“照片”App 的“最近删除”，不要先恢复出厂设置。
检查 iCloud 照片、共享图库、其他 Apple 设备和既有电脑备份。
暂停大量拍摄、下载和应用清理，避免系统继续产生大量新缓存和数据库变化。
在有足够空间的电脑上保留一份完整备份，再对副本分析。
导出后验证文件能否打开，不要只看软件显示的条目数量。
这些措施不能保证恢复成功，但能减少不必要的状态变化，并保留更多可验证的来源。
当前产品的边界
使用 Apple MobileBackup2 逻辑备份采集与解析。
默认保持原始备份不变，在任务目录的工作副本中处理数据库。
能检查相册媒体、照片数据库、部分缩略图/派生资源、联系人、短信、通话记录和 App 缓存。
只支持未加密本地备份；不绕过密码，不做 NAND 雕刻，不做 Full File System 提取。
结果按原文件、派生副本、缩略图、仅元数据及删除证据分类。
真机删除实验的支持矩阵仍需继续验收，因此不承诺固定恢复率或所有 iOS 版本都能找回同类内容。
想实际检查自己的设备，可以先阅读带截图的完整使用教程，再从官网下载 Windows 版。