为了找一张图，我在自己亲手建的库里翻了 41 分钟
上周三下午三点多，我想找一张参考图。2019 年在东京拍的，雨天，便利店门口，暖黄色灯箱，地上有积水反光。我知道它就在我的 Eagle 库里，因为是我亲手拖进去的。我在搜索框里敲了「便利店」「雨」「日本」「灯箱」「黄色」，翻到第 20 屏，最后在一个叫「新建文件夹(3)」的文件夹里找到了它。文件名是 IMG_4471.JPG。当时我的第一反应不是生气，是有点荒诞——我建这个库，不就是为了不出现这种事吗。
那天晚上我给这个库做了一次体检。库文件夹 87.4GB，28431 个条目，其中 psd 和 ai 加起来 6127 个，mp4 有 300 多个，剩下是 jpg 和 png。那个 metadata.json 已经涨到 70 多 MB。双击一个素材，预览要 3 到 5 秒才出来，搜索框输完关键词，结果列表得愣 1.5 到 2 秒才刷新。我一度以为是那块 2TB 机械硬盘的锅，把整个库挪到 NVMe 上，确实快了一点，但打开大 psd 预览还是要 2 秒多。
卡的不是硬盘，是「一个库装所有东西」这个结构本身
我后来想明白了一件事。Eagle 的工作方式是：它启动时要把整个库的目录结构、标签、评分、注释全部加载进内存，检索的时候再在内存里过一遍。库越大，启动和检索的固定开销就越高。这跟你的硬盘多快关系不大——硬盘只影响加载的那一刻，检索本身是 CPU 在跑。2.8 万条的时候还能忍，我朋友做电商设计的，库里 9 万多条，他说搜索要等 5 秒以上，已经属于「能不用就不用」的状态了。
所以问题不在工具，在我一开始的假设：把「所有可能用到的素材」塞进一个地方，就等于管理好了。这是错的。一个库如果要同时承担「长期囤积」和「当前项目调用」两个职责，它必然会被前者撑爆，然后拖累后者。
顺便说个更早的翻车。2021 年我试过用 Notion 数据库存情绪板，觉得又能打标签又能写备注还能协作，简直完美。免费版单文件上传限制 5MB，这我忍了，压缩一下就行。真正的问题是链接。通过 Notion API 上传的那批图，返回的 S3 链接是有有效期的，我当时不知道。2023 年我打开那份情绪板，一半的图是裂开的图标。手动拖进去的图片稍微稳一点，但我也遇到过重新加载。
元数据到底存在哪，这才是选工具的分水岭
我现在判断一个素材工具值不值得长期用，只看一条：我写的标签、评分、注释，存在文件里还是存在软件的数据库里。
Eagle 的标签存在库文件夹的 metadata.json 里，Lightroom 的评分和关键词存在 .lrcat 目录文件里，Notion 存在云端。这意味着什么？意味着你哪天不用这个软件了，导出成散装文件夹，3 万个标签瞬间归零，剩下的只有 IMG_4471.JPG 这种名字。你花了三年建的知识体系，跟着软件一起死。
反过来，如果你把关键信息写进文件名、文件夹层级，或者给图片配上 .xmp sidecar 文件（Lightroom、Bridge、Capture One 都认这个格式），那这些信息是跟着文件走的。换个软件、换台电脑、直接丢进 Everything 里搜，照样能用。我的做法是：只给最核心的那 20% 素材（经常复用的、有明确项目归属的）写规范文件名，剩下的长尾素材就接受它是一堆无名文件，反正一年也用不上两次。
我现在的两层结构：素材池 + 项目库
素材池，按来源和年份分，比如 _Pool/2024/手机拍摄/，只进不出，不做任何精细整理，不建标签。它的定位是「原始档案」，我基本不指望能靠搜索在这里捞到什么，捞不到就当没有。项目库，按客户或项目分，比如 CoffeeBrand_2024Q3/，项目结束就整个打包归档到 _Archive/，硬链接或者直接移动都行。这一层才是我每天真正在用的。
两层的分界线是「可检索的规模」。素材池我放任它长到十几万条都无所谓，因为我不在里面搜；项目库一般控制在 2000 条以内，标签和命名都做到位，这个规模下找东西是几秒钟的事。
| 方案 | 花钱 | 标签元数据存哪 | 3 万条时的检索手感 | 换软件后剩什么 |
|---|---|---|---|---|
| Eagle | 29.95 美元买断，约两百多人民币 | 库文件夹里的 metadata.json | 搜索 1.5 到 2 秒出结果 | 只剩文件夹和原始文件名 |
| Billfish | 免费 | 同样是自己的库文件 | 我用到 1 万多条时还流畅 | 同上 |
| 纯文件夹 + Everything | 0 元 | 文件名和文件夹本身 | 索引建好后几乎瞬时 | 全都在 |
| Notion 数据库 | 免费版单文件 5MB | 云端 | 图多了会转圈 | 链接可能失效 |
命名和搜索的具体规则，照抄就行
文件名格式我用 20240315_便利店雨夜_参考图_01.jpg，也就是「日期_项目或场景_类型_序号」。日期用 8 位数字，排序时天然有序；场景用中文，因为我的搜索习惯就是打中文；序号补零，避免 1 排在 10 后面。文件夹层级我强迫自己不超过 3 层，因为超过 3 层人类记不住路径，你会在第 4 层开始瞎建「新建文件夹(2)」这种东西。
搜索靠 Everything 补位。几个我天天用的语法：ext:psd;ai 搜多个扩展名，dm:2024-01-01..2024-12-31 按修改日期筛，size:>10mb 筛大文件，regex:^2024\d{4}_ 用正则匹配我的命名规范，content:关键词 可以搜文档内部的文本，前提是你在选项里开启了内容索引，不然它不干活。Mac 用户可以用终端里的 mdfind -name "关键词" 配合 Spotlight 的智能文件夹，原理差不多。
去重这件事我建议你找个周末一次性做完。dupeGuru 免费，但默认是按文件名比对的，你得手动改成按内容哈希；Windows 上还有 AntiDupl，是按图像像素相似度比，能抓到缩放过的重复图。我去年清出来 4217 张重复，删完之后库体积从 104GB 降到 87GB。
每周日晚上花 20 分钟，比什么都管用
我现在固定周日晚上花 20 分钟做三件事：把本周新下载的素材从下载文件夹挪进素材池对应年份；检查项目库里有没有做完但没归档的项目；清空回收站。就这三件，多了我坚持不下来。
说实话，我现在对素材这件事的态度比三年前冷多了。以前看到好看的就存，觉得迟早用得上，存了 2.8 万条，真正用过的大概不到 800 条。素材库不是收藏夹，收藏这个动作本身能缓解焦虑，但它不解决任何问题。工具箱才解决问题——你需要的东西在 30 秒内能找到，这就够了。
现在那张便利店的照片，我把它重命名成了 20190412_东京便利店雨夜_参考图_01.jpg，放在项目库里。上周我用了它一次，找它花了 8 秒。