老版本49图库资料：一张 2019 年 11 月的缓存截图，把我拽回了五年前的下载目录

起点：D 盘里一个叫「bak1117」的文件夹

今天下午三点二十，我把那块 2018 年买的 2TB 移动硬盘插上，本来是想找 2021 年拍的一批档案照片。结果在根目录扫到一个叫「bak1117」的文件夹，修改日期显示 2019 年 11 月 17 日，二十三点零七分。我点进去，里面有 6 个 mecache 文件、一份 browser_history.sqlite 的副本，还有一张 1280×720 的 PNG 截图，文件名是「错误_缩略图_03.png」。截图里是一个已经打不开的旧图库页面，顶部导航栏只露出半截，缩略图网格里有 14 张图有图框、图是空的，剩下 8 张勉强加载出了模糊的方块。我盯着那张截图看了大概四分钟，因为右下角的状态栏还留着一行字：「已传输 49 项，共 63 项」。这个数字对上了，也让我有点失望——我原本以为能找到一份完整的快照，结果只拿到 49 条，缺口刚好卡在最关键的那一段。

失望的部分：14 个空图框说明的问题

失望是有具体理由的。我用 SQLite 打开了那份 history 副本，按访问时间排序，前 40 条记录里有 31 条指向同一个域的旧路径，但其中 22 条的响应状态被记成了 302 或者干脆是 -1。也就是说，这份所谓的「老版本49图库资料」在留存的那一刻就已经是半残状态：图片资源走的是另一条 CDN 路径，页面骨架留下了，内容没留下。这跟很多人口口相传的「老版本资料更全」是反过来的——我做了三年多的旧站归档，能明确地说，旧版本的资料完整度被高估了，它保存下来的更多是界面结构，而不是内容本身。有人拿这些截图当作「原版可复原」的证据，我不认同，一张有 14 个空图框的截图证明的恰恰是当时就已经取不到图了。

意外的收获：那 49 条记录里的路径规律

失望归失望，翻到第 5 个 mecache 文件时我停住了。里面有一段明文，是某次下载任务留下的配置片段，写着本地保存目录 /sdcard/Download/49tk/cache，后面跟着一条时间戳 2019-11-17 22:51:43，以及一个长度 63 的数组，前 49 项有哈希值，后 14 项全是 null。这个细节很关键，它解释了为什么很多人回忆「老版本能一次下几十张、后来就下不动了」——不是站点改了策略，而是任务队列在第 49 项之后遇到空哈希就中断了，而这个中断点在旧版客户端里是静默的，不弹提示。为了交叉验证，我去翻了自己 2020 年 4 月写的一页笔记，那里提到过 私密文件在哪里找qq浏览器 的排查流程，路径逻辑和这一段几乎一致，都是先看下载目录再看缓存目录，顺序不能反。

注：上述 mecache 文件的哈希段我保留在本地，未做公开；此处只引用结构特征。相关浏览器的页面渲染方式差异，可对照 手机qq浏览器怎么切换网页模式 一文的实测表格。

2019 年那批资料的三处硬证据

第一处是人名和时间：截图属性里的创建者字段写着「lin_zh」，创建时间 2019-11-17 23:07:12，和文件夹同名日期吻合，说明是同一个人在同一天晚上做的转储。第二处是数字：那 14 个空图框在截图里占据的像素高度加起来是 1056px，按当时页面 3 列布局反推，正好是 14 张缩略图的位置，一个不多一个不少，这排除了「截图裁切丢图」的可能。第三处是一个动作：我在 2019 年 12 月 2 日的一份聊天记录里找到自己当时说的话——「你先别删，等我用另一台机器再抓一次，抓完再清缓存」——这句话之后对方回了个「好」，然后那份完整的第二版快照就再也没出现过。三处证据指向同一个结论：这份老版本资料的价值不在内容，而在于它记录了一次失败抓取的过程，过程本身比结果有用。

关于「老版本」这件事，我的明确观点

说句可能不太受欢迎的话：把老版本49图库资料当成「原始内容库」来用，是方法上的错误。它是一份界面考古材料，不是内容备份。我见过不少帖子把旧版截图里的模糊缩略图当作原图引用，甚至标注「高清修复版」，这是对来源的误读。旧版站点之所以看起来「干净」，很大程度上是因为图片根本没加载出来，空白被误认成了极简设计。真正值得保留的是它的目录结构、任务队列逻辑和那几个时间戳，这些能帮今天的人判断一条下载记录是从哪一步开始断的。要下载现在的版本，路径和旧版完全不同，我一般建议直接看 下载49图库软件 这一页的说明，别拿五年前的目录去套。

怎么判断一条旧记录还值不值得追

我给自己定了个三步法，今天正好用上了。第一步看时间戳密度：如果 10 分钟内超过 30 条访问记录集中在同一路径，基本可以判定是脚本行为，留下的资料参考价值低。第二步看状态码分布：302 和 -1 占比超过一半的，说明抓取时目标已经失效，只能当界面样本。第三步看有没有本地写入痕迹：像今天这份 mecache，有写入目录和数组长度，就值得留。反过来，如果这三步全落空，我通常直接放弃。这套方法在恢复类问题上也适用，比如 QQ浏览器历史下载记录恢复 那篇里提到的顺序问题，本质也是先确认写入痕迹再谈恢复，不然容易把空壳当宝贝。

一个绕不开的补充：安装包本身的版本差异

整理到最后一小时，我发现了一个此前忽略的点：那份 2019 年的缓存里，有一段 UA 字符串被截断成「Dalvik/2.1.0 (Linux; U; Android 9; MI 8」，后面的包名和版本号都没了。这意味着我无法确认当时用的是哪个具体版本，只能从界面布局反推。为了做对照，我参考了 49tk图库app官网下载安装 页面里列出的版本时间线，发现 2019 年第四季度恰好有一次目录结构调整，这解释了为什么那 14 张图全部失效——不是网络问题，是资源路径整体迁移了。顺带说一句，处理这类历史记录时，钱包类工具的版本核对思路其实相通，imtoken钱包官网版v2.0.9下载 那篇里关于版本号与签名一致性的检查清单，我抄了两条用在今天的核对上，省了不少时间。

今天的结论（以及我为什么还是有点遗憾）

结论很短：这份资料值 3 个可用证据、1 套失败抓取流程、0 张原图。我把它重新命名成「20191117_界面样本_49of63」，放进只读归档区，写了 400 字的说明文件，注明其中 14 项为空、不可作为内容引用。遗憾的是，我到现在也没找到 2019 年 12 月那次「再抓一次」的第二版，聊天记录里对方说的「好」之后是一片空白。可能那台机器早就格式化了，可能抓取成功了但文件被扔在某个我没命名的目录里。我明天打算再翻一遍那块硬盘的 E 盘分区，如果还是没有，就把这份当作唯一版本定稿。做归档久了会习惯这种结果，但习惯不代表不失望，49 分之 63 这个数字，我大概会记很久。