从那张 87KB 的截图说起
昨天下午三点，我在旧笔记本电脑的下载文件夹里翻到一张 2019 年 11 月的截图，是当时用手机拍下的一块白板，上面有周明远写的三行架构草图。文件大小 87KB，尺寸 1280×720，EXIF 里只剩拍摄时间和一个被截断的设备型号。我想把它恢复到原图，至少恢复到能看清字迹的程度。
结果恢复工具给出的「原图」选项，实际上是一次基于缓存的超分辨率重建，并非找回原始文件。这个细节让我有点失望，但也让我决定把这段过程写下来。
我用了三个不同工具交叉验证。第一个工具声称能从系统缓存里提取 2048px 的预览图，实际导出的是 1024px，且白板右下角的算式「2^10 = 1024」仍然糊成一团。第二个工具走的是云端回收站路径，找到了两张 2020 年 3 月的重复上传记录，但那是另一块白板。
为什么「原图」这个词总让人误解
很多用户第一次接触恢复图库到原图恢复，是在手机相册弹出「存储空间不足，建议优化照片」的时候。系统把原图上传到云端，本地只留一个压缩副本。等到某天想找回原图，才发现云端版本可能已经被二次压缩，或者账号同步出现断档。
我在 2025 年 12 月做过一次小样本统计，检查了自己图库里 40 张标记为「原图」的照片，其中 9 张的实际分辨率和 iCloud 记录不一致。这不是个例。如果你需要从本地文件层面排查，可以参考我整理的< a href="/p508811-fe11.html">qq浏览器打开本地文件那篇笔记里的路径检查方法。
真正有效的恢复策略通常分三层：先查本地缓存目录，再查云端版本历史，最后才是像素级重建。前两层是「找回」，第三层是「猜」。我个人的观点是：把第三层结果称作「原图恢复」是不诚实的，它应该叫「原图重建」。
一个具体的操作序列
那天晚上九点四十，我按顺序做了四件事。第一，把原始文件复制到只读目录，防止任何工具二次写入。第二，用系统自带的照片应用导出「未修改的原件」，确认导出大小仍是 87KB。第三，检查与图库关联的< a href="/p23656-4392.html">正版图库账号的同步历史，发现 2019 年 11 月的上传记录存在，但版本号只有 v1。第四，才打开重建工具，把强度调到中档。
最后得到一张 2560×1440 的图，白板上的「周明远」三个字能看清了，「2^10」也能辨认，但架构草图的箭头全部被平滑成了模糊的曲线。这就是重建的代价：它优先保证整体观感，牺牲了局部结构。
给同样在找原图的人
如果你也在做类似的事，我的建议是先把期望拆开。要的是「能看清内容」，重建够用；要的是「拿回当年那个文件」，那就只能老老实实查缓存和云端历史。登录入口这类操作，有时候会牵扯到网页端的历史记录，我一般参考< a href="/post-493338.htm">qq网页版登录界面的流程来核对账号状态，避免在错误的账号里白找。
今天的状态是失望多过收获：87KB 的那张截图终究没有回到 2019 年的原始状态。但意外收获是，我理清了一套可以复用的检查顺序，也算没白忙。
