恢复原来的49图库版本 笔记

一、从一块 2019 年的移动硬盘说起

昨晚十一点半，我把那块 2019 年买的西部数据移动硬盘插进旧笔记本，风扇声一下子起来了。D 盘里有个叫「tuKu_old」的文件夹，日期停在 2021 年 3 月 14 日。我点开它之前，先给自己泡了一杯茶，因为我知道接下来要做的事情不适合着急：恢复原来的49图库版本，听起来像一句口号，做起来其实是一件需要反复核对、反复放弃、再反复回来的笨活。那一刻我很平静，甚至有点满足，像是终于坐到书桌前，面对一份搁置了很久的旧作业。

先说结论：我没有「修好」它，我只是把它重新读了一遍。

文件夹里有三样东西。第一是一个只有 12 行的 index.html，连 script 标签都没有，全靠静态结构撑起来；第二是一个 json 索引，176 条记录，字段名干净得让我有点意外——id、title、thumb、tags，四个字段，不多不少；第三是四张分类封面图，分辨率都是 400×300，文件名还保留着拼音缩写。我把这个目录整个复制到桌面上，重命名为「tuKu_old_backup_20251201」，然后才开始动手。这是我自己定的第一条规矩：任何覆盖之前，先给原始文件留一个不会被动到的副本。听起来很基础，但我在 2023 年的时候因为没有这么做，丢过一次整理了三周的标签数据，那次教训我记到现在。

二、176 条记录和 900 多条之间的差距

旧索引只有 176 条记录，而现在的版本有 900 多条。数字上看是五倍多的差距，但真正让我停下来想的是加载时间：旧索引在本地的打开时间大概 0.3 秒，现在的版本即使做了懒加载，首屏也要一秒出头。我一开始以为是数据量的问题，后来逐字段对比才发现，问题根本不在条数，而在字段冗余。旧版本每条记录只存缩略图的相对路径，现在的版本同时存了原图路径、缩略图路径、以及一组尺寸参数，字段一多，解析开销自然上去。这不是谁对谁错的问题，但当我决定恢复原来的49图库版本时，我要恢复的其实是这套「只留必要字段」的克制。

恢复的本质，是恢复判断，不是恢复像素。

这句话我写在便签上，贴在显示器边框。因为做到一半的时候我差点跑偏了——我看到旧版的分类栏间距更小，就想把现在的间距也调回去，调了大概四十分钟，越调越别扭。后来我打开控制台量了一下，旧版是 12px，现在的是 14px，只差 2px，但视觉上的「不一样」在心理上被放大了好几倍。我最终没有改间距，因为那 2px 的差别在移动端反而更合适。这一段我后来写在 changelog 里，标注为「已评估，不采纳」。记录本身比恢复更重要，这是我做完这件事之后最确定的一点。

三、一次 404 带来的排除法

中间有个小插曲。我一开始以为是浏览器缓存的问题，清了三次缓存，页面没有任何变化。后来按 F12 打开控制台，看到一条 404，指向一个我 2024 年就改过名字的缩略图目录。问题根本不在缓存，而在一个我早就忘了的路径引用。这件事提醒我：在做恢复原来的49图库版本这类工作的时候，最忌讳的就是凭经验下判断。我后来用同一个旧文件在三个浏览器里各打开一次，包括参考 qq浏览器怎么打开网址 里的方法做的交叉验证，渲染结果完全一致，才确认问题出在文件结构本身，而不是浏览器。这个排除法前后花了不到二十分钟，比我清缓存省事得多。

先看控制台，再清缓存。顺序错了，时间就白花了。

交叉验证这件事我还有一点补充。同一个文件在不同浏览器里表现一致，只能说明问题不在这三个浏览器的实现差异上，不能说明文件就是对的。所以我又把旧索引和现在的 49 图库app 的数据结构做了并排对照，把两侧的字段名列在一张 A3 纸上，用红笔标出增删。标完之后我笑了：旧版有四个字段，现在有九个，多出来的五个里，有三个是纯展示用的。也就是说，恢复原来的49图库版本，最值得保留的可能不是界面，而是那份「不做多余的事」的结构判断。这个观点有点争议，我知道会有人不同意，但我还是愿意把它写下来。

我不认为旧版本在功能上更好。它只是更少。而「更少」在 2021 年是一种选择，在今天则成了一种需要刻意维护的立场。

四、收尾：写在便签上的 changelog

最后一步很普通。我把这次改动写在一张 A5 便签上，贴在显示器边框：日期 2025-12-01，改动点三项——索引字段精简、缩略图路径修正、分类封面图替换为原件；回滚方式一项——直接使用桌面的 tuKu_old_backup_20251201 目录覆盖。写完我重新打开了一次页面，从首页点到分类页，再从分类页点回详情页，确认没有断链，然后把茶喝完。今天的状态大概就是这样：平静，满足，像刚泡完一杯茶。我顺手又看了一眼 49图库正版首页 的分类顺序，确认结构逻辑还在，才关掉屏幕。这篇笔记就写到这里，剩下的留给下一次恢复。