打开图库浏览，
看到的是一地鸡毛。

昨天下午两点十七分，我打开图库浏览，想找一张去年 4 月在苏州拍的石桥。输入“苏州”，跳出来 1,843 个结果。我盯着那个数字看了十秒，然后关掉了窗口。

不是找不到。是我不敢翻。前 200 张里有 47 张是同一座桥，文件名从“IMG_2047”到“IMG_2093”，修改时间全部落在 4 月 12 日上午 9 点到 10 点之间。我花了整整 53 分钟拍同一座桥，回去之后一张没删，一张没改名字。现在它们安静地躺在那里，像一排没有门牌号的房子。

这件事得说清楚。我把问题归成三类。第一类，命名。相机默认的编号在我这里完全失效，因为我有三台设备，每台的计数器都会回到 0001。第二类，重复。一张图经过微信、截图、另存为三次转手，体积从 4.2MB 变成 800KB，肉眼看起来一样，哈希值不同。第三类，索引。我装过四个图库软件，每个软件都有自己的数据库，没有一个能读另一个的标签。

命名是一场公开的失败

我试过一套完整的编号规则：日期加地点加序号。规则写在便利贴上，贴在显示器左边。第一周执行得很好，4 月 8 日到 4 月 14 日，共 312 张，全部合规。第二周出差，回来之后有 89 张没有立刻导入，堆在相机卡里。第三周，我在便利贴上又加了一条规则，然后第四周开始不看了。两个月后，图库里同时存在四种命名格式，外加 11 个“未命名文件夹”。

周明远来我家看了一次。他打开图库浏览，滚动鼠标滑轮，滚了大概四十秒，然后停在一张模糊的夜景上，问我，这张是什么时候的。我说不知道。他说，那你留着干嘛。我没回答。他也没再问。后来我翻到那张图的属性，拍摄时间是 2021 年 10 月 23 日 21:47，地点是绍兴。但属性里没写我为什么会拍它。

我现在的做法很粗暴。所有图片按月归档，文件夹名就叫“2026-01”。里面不再建子目录。每张图按“年-月-日-序号”重命名，用脚本跑。跑完再看一遍，把明显没用的删掉。删不掉的，承认它们就是删不掉，放在一个叫“留着”的文件夹里。这个文件夹现在有 2,144 张图，占用 6.7GB。

承认失败之后，整理反而快了。我不再追求“完美分类”，只求一件事：想找某张图的时候，能在 30 秒内定位到年份和月份。至于精确到哪一张，靠记忆。记忆不可靠，但比索引可靠。

如果一套方法需要你每天都严格执行，它注定会失败。整理是给懒人准备的工具，不是给自律者准备的仪式。 —— 我写在笔记本第一页的话，2025 年 6 月

重复文件是诚实的朋友

上个月我跑了一次全盘查重。工具叫 fdupes，命令行，跑完生成一份 41 页的报告。结果很有意思：重复率最高的不是照片，是截图。一张 2023 年 8 月 6 日的报价截图，在图库里出现了 14 次。每次都是从不同的聊天窗口另存出来的，尺寸略有差异，内容一模一样。我删了 13 张，留下最早那张。

照片的重复是另一种。它们不是因为转发，而是因为我拍了连拍。2024 年 5 月 2 日，在南京老门东，我拍一只趴在墙头的猫，连拍了 38 张。每张之间差 0.2 秒，猫的耳朵角度不同。我最后留了第 6 张和第 31 张。剩下的 36 张，删的时候有点犹豫，但还是删了。说实话，那 36 张里，有 5 张其实比留下的两张更好。只是我没时间再看一遍。

查重之后，图库从 31,208 张降到 22,486 张。体积少了 18.3GB。打开图库浏览的速度从 8 秒变成 4 秒。我盯着这个变化，不知道该高兴还是该难过。

索引是唯一的出路，也是最深的坑

我现在用 sqlite 维护一份自己的索引表。三列：路径、哈希、标签。标签手动加，目前加了 312 张，剩下的还没动。查询速度很快，0.3 秒。但维护成本高：每次导入新图，要跑一次脚本，更新哈希；每次改标签，要写 SQL。这不算麻烦。麻烦的是，我总在想，这套东西能撑多久。

撑到明年，大概没问题。后年就难说。因为文件会越来越多，标签规则会变，设备会换。所有的整理方案都有一个共同的结局：使用者放弃维护，然后打开图库浏览，看着一堆没有索引的文件发呆。我见过太多这样的场面，包括我自己的。

所以现在我的态度变了。不再为了“将来某天能找到”而整理，而是为了“今天能删掉多少”而整理。删掉的东西不会再来打扰我。留着的，就当它们不存在。这个观点可能很消极，但我认为它比任何一套整洁的文件夹结构都诚实。

如果你也在整理自己的图库，我只有一句建议：先删，再命名。反过来做，你会卡在第一步很久。至于索引，等你删到一万张以下再考虑。在那之前，打开图库浏览，看到的每一张图，问自己一遍：下次用它是什么时候。答不上来，就删。答得上来，改名，放进当月文件夹。就这样，别想太多。