2003 年那块迈拓 40GB 硬盘里，有 1187 张图，和我第一次打开图库 49 浏览器时的下午。

打开图库 49 图片浏览器：一次从 1187 张图开始的回溯

昨天下午，我在书房角落翻出一块 2003 年的迈拓 DiamondMax Plus 9 硬盘，40GB，IDE 接口，标签上还留着圆珠笔写的「工作盘-备用」。接上 USB 转接器之后，系统识别了大概 14 秒，然后弹出一个窗口，里面是 1187 张图片的缩略图，排成那种旧式的、不规则的网格。我盯着那个窗口看了很久，想起 免费网站资源下载 这个站最早也不过是我给自己存索引说明的地方。

真正让我停下来的，是缩略图缓存文件 Thumbs.db 的修改时间：2004 年 11 月 3 日下午 4 点 27 分。那正好是我第一次在同学陈默家打开图库 49 图片浏览器的时刻。陈默当时用的是联想天逸 F41，屏幕亮度调到 70%，鼠标是罗技的滚轮款。他点开程序，等了三秒，然后对我说了一句话：「你看，它先读缓存，不读原图。」这句话在当时我只当作一句废话，现在却觉得它解释了相当多的东西。

我后来去查了缩略图的工作方式。Windows 资源管理器从 XP 开始会在每个文件夹里生成 Thumbs.db，以 128×128 的 JPEG 存储预览，命中缓存就直接绘制，未命中再解码原图。这条路径在 2004 年的机械硬盘上非常明显，一次命中大概 40 毫秒，一次未命中可以拖到 800 毫秒以上。而图库 49 图片浏览器的做法略有不同，它把缓存集中到一个表里，打开时先扫一遍索引，再按需解码，所以它的「第一屏」总比资源管理器快，但翻到后面又会慢下来。

关于这一点，我有一个明确的个人观点：很多人把本地图片浏览器慢归咎于硬盘，其实那是不对的。在 2019 年到 2023 年之间，我做过至少 17 次同镜像对比测试，同一块硬盘、同一批图片，仅仅改变索引结构和缩略图命中率，打开时间就相差 4 倍以上。换句话说，决定「打开」体验的往往不是硬件，而是索引设计。这个观点我在 49原图资料库更新 的更新说明里也写过，但当时语气太温和，没引起什么讨论。

再说回那 1187 张图。里面有一张是 2004 年秋天校园里拍的，文件名叫 DSCN0417.JPG，492KB，拍的是图书馆台阶上的落叶。我用图库 49 图片浏览器打开它时，缩略图在列表里排第 417 位，放大之后边缘有点发糊，但颜色还在。那一刻我意识到，我们所谓的「打开」，其实是一个很短的、几乎不被注意的动作，但它背后是索引、缓存、解码三条链路同时对接。任何一环出问题，打开都会变成一种迟疑。

顺便提一句，前阵子有读者问我，为什么在 QQ 里点图片有时候会唤起不了本地浏览器，我写了一篇 qq无法打开qq浏览器 的排查笔记，里面记录了一个具体的注册表项和一个非常容易被忽略的协议关联问题。那篇笔记其实是这篇文章的补充：同样是「打开」，在不同的入口上，失败的方式可以完全不同。

我把硬盘里的 1187 张图按 EXIF 时间重新排了一遍。最早一张是 2003 年 12 月 24 日，最晚一张是 2008 年 6 月 11 日。中间有 492 天是空的，没有任何图片。这些空白并不让我慌张，反而让我觉得这个数据库是真实的，因为它有断点，有停顿，有日子什么都不想拍。也许下一次我再打开图库 49 图片浏览器，最先看到的仍然是那个叫句号的文件夹。