iPhone已删照片为何能在缓存留存数年：从PhotoData看系统的惰性清理权衡

你在 iPhone 上清空最近删除的那一刻，只删掉了一半。

几天前，一位开发者把手机连到 MacBook 上做本地备份。 他顺手让命令行里的 AI 工具 Claude Code 扫了一遍系统文件。 结果工具在深层目录里抓出了一个叫 PhotoData/Thumbnails 的文件夹。 里面密密麻麻，堆着几千张图片、视频和截图。

最诡异的是，里面大量的内容，全是他早就删掉的东西。 三年前截取的银行 App 界面。 随手拍坏、两秒钟内就扔进废纸篓的自拍。 在“最近删除”相册里特意手动清空过的各种私密照片。 它们不仅没有消失，还整整齐齐地躺在这个缩略图缓存里。

手机系统在偷偷监控吗？ 没有。 这背后不是阴谋，是一场非常典型的操作系统工程妥协：速度与彻底之间的权衡。

要想弄明白照片为什么删不干净，得先看 iPhone 是怎么存照片的。 现在的手机镜头动不动四千八百万像素，一张高清原图动辄几十兆。 相册里如果有五万张照片，如果每次滑动屏幕，系统都要去闪存里读取原图，手机芯片会当场卡死，电池也撑不过半天。

为了让相册能在 120 赫兹高刷下丝滑滚动，也为了让系统的全局搜索能秒出结果，系统做了一个拆分。 每次你拍下一张照片，后台的媒体服务程序 assetsd 会同时处理三件事。 第一件，把高清原图存进存储区。 第二件，在主数据库 Photos.sqlite 里登记照片的拍摄时间、地点和参数。 第三件，立刻把原图压缩成几种不同尺寸的低分辨率小图，塞进 PhotoData/Thumbnails 目录和搜索缓存里。

也就是说，相册里看到的每一张缩略图，物理上跟原图是分开存放的。

当你在相册里点下删除，再去清空“最近删除”的时候，系统到底做了什么？ 数据库收到指令，把主数据库里的索引记录抹掉了。 存储高清原图的那个区块，链接被切断，对应的加密密钥被销毁。 那张几十兆的高清大图，确实在物理层面上消失了。

可那些缩略图呢？ 系统根本没有在同一秒去清理它们。 为什么不顺手一起删掉？ 因为闪存擦除数据是以区块为单位的。 这些缩略图只有几十 K，往往被打包拼合在大块的缓存文件里。 如果每删一张截图，系统都要唤醒芯片、重写闪存块、更新索引，不仅极度耗电，还会大幅增加闪存芯片的磨损。

所以系统架构师选了另一种策略：惰性垃圾回收。 先只删主指针，告诉用户“已经删完了”。 至于那些散落的缩略图碎片，等什么时候手机存储空间极度紧张了，或者等到夜间闲置维护的时候，再去批量清理。

可问题在于，如果你的手机买的是 256G 或 512G，平时还有几十个 G 的空余容量呢？ 那这个自动清理的警报就永远不会被触发。 主数据库里的指针没了，相册界面显示空空如也。 但那些已经失去索引的孤儿缩略图，就这么安安静静地在闪存深处躺了三年。

这在数字取证领域，早就是公开的常规操作。 调查员使用 Cellebrite 或 GrayKey 这种取证设备恢复已删数据时，第一步去搜的永远不是相册原图，就是 PhotoData 这个缩略图缓存和 SQLite 的临时日志。 哪怕原图早被粉碎，几百像素宽的缩略图，也足够看清银行账单上的数字、证件上的姓名和截图里的文字。

2024 年 5 月苹果推送 iOS 17.5 的时候，全网爆出过一则轰动新闻。 很多用户更新完系统后惊恐地发现，自己早在 2010 年就删掉的私密照片，居然重新冒出来挂在相册第一排。 当时网上各种恐慌，怀疑是不是云端服务器在永久留存用户的废弃数据。 随后官方紧急发布了 iOS 17.5.1，并在技术说明里澄清了原因。 根本不是云端在搞鬼，就是本地数据库重建索引时的 Bug。 系统在升级时重新扫描本地文件系统，撞见了这些在底层从未被真正清理掉的孤儿文件，误以为是新发现的照片，又把它们重新挂回了相册。

那为什么平常用手机感觉不到？ 因为在手机系统内部，每一款第三方 App 都在严格的沙盒机制里运行。 普通软件拿不到深层系统文件的读取权限，根本摸不到 PhotoData 这个目录。

但真正的缝隙出现在跨设备的时候。 就像这位开发者遇到的情况一样。 当你把手机插上电脑，通过 Finder 做了一个未加密的本地备份。 整个原本被沙盒保护的目录结构，被原封不动地倒进了电脑的硬盘里。 在电脑端，只要任何软件或者命令行工具拥有了磁盘访问权限，就能把这些留存了数年的历史缩略图看得一清二楚。

只要手机存储空间足够大，那套清理逻辑就不会执行。 你在相册里点下删除，系统向你保证的是界面变干净了，不保证闪存里的每个字节都被即时抹平。 速度、电池寿命和彻底擦除之间，工程师终究得选一边。