凌晨三点十七分，我在光标和缩略图之间反复切换，试图弄清这十七张图的排序逻辑。
昨天深夜，为了给一份地方志配图，我打开新奥门17图库，在“十七图”预览区里逐个点击文件名——从“奥-001”到“奥-017”，文件详情页的加载条走了大约四秒。我盯着那个被标记为“批量标签”的按钮，忽然意识到自己已经三年没认真读过一份图库产品的功能说明。于是决定写下这篇详解，哪怕大部分问题我目前还没有答案。
林葭那天带了一台二手富士 X-T20，在档案馆地下室连续拍了 47 张微缩胶卷转印本。她后来把其中 12 张上传到新奥门17图库，尝试用“批量描述”功能一次性写入日期和馆藏编号。她的抱怨是：批量描述无法自动继承上一张的 EXIF 信息，每次都要手动勾选“保留当前位置”。这个细节我在实际操作中复核过，确实如此。
但她承认，标签联想的速度比三年前快了不少。
关于新版工具的下载决策，她曾在微信里问我：“新版49图库app值得下载吗？”我没能给出确切答案，因为我自己还在试用。不过她最终装上了，理由是“至少缩略图不再糊成一片”。
新奥门17图库的“十七图”不仅是一个数字标签，它实际上是一个前端缓存的分组单元。根据我的测试，每一组十七张图的缩略图在本地存储中保留大约 72 小时，之后会按照最近访问时间淘汰。这个行为没有写在任何官方说明里，是我用开发者工具查看 IndexedDB 时注意到的。
这意味着如果你三天内不翻那组图，下次打开就得重新加载。
我个人的看法：这个设计对内存友好，但违背了“图库即档案”的直觉。我更喜欢永久缓存缩略图，哪怕多占几十兆。当然，这只是我一个人的偏执。另一个相关的问题是浏览器端隐私文件的管理，我曾在另一篇笔记里提到过 新版qq浏览器私密文件 的存储位置，其实思路相通——缓存策略决定了你下次打开时的等待时间。
我朋友陈默是城市规划师，上个月他在新奥门17图库的搜索框里输入“1987 解放路 自行车”，从按下回车到看到第 14 张结果，计时器显示 17 秒。他当时说了一句：“比上次快了将近一倍。”这个数字我记在笔记本上，因为“快一倍”这种说法很少从他嘴里冒出来。他的具体操作是先用“标签导航”过滤掉彩色照片，再手动输入年份。
搜索框的联想提示确实变得更具体了。
不过他也提到，如果同时用两个浏览器打开同一个图库页面，搜索结果会出现轻微的排序差异。我怀疑是分页游标的问题。这让我想起那个老梗——474747浏览器打开一百度网 之类的问题，往往出在你以为是缓存、其实是会话隔离没做好。
赵一舟是独立开发者，他写了一个使用 Tampermonkey 的脚本，用来给新奥门17图库里每一组“十七图”批量加前缀。他的脚本运行了 4 分 12 秒，处理了 17 组、共 289 张图。其中 3 张因为文件名含有特殊字符被跳过。他事后在 GitHub Gist 上写了三行注释：“图库的 API 没有提供批量重命名的端点，只能靠 DOM 事件模拟。”这句话我反复读了几遍，确实如此。
他最近在找更稳定的替代方案。
赵一舟提到他也在关注 49图库恢复正常使用精准49图库 的进展，因为那套系统的批量导入逻辑似乎和新奥门17图库有相似之处——都是先解析 manifest 再生成缩略图队列。他原话是：“如果恢复之后的表现稳定，我可能把脚本移植过去。”
我在测试“版本回溯”功能时，对同一张摄于 2019 年 4 月 7 日的产品图进行了 23 次编辑，每次只改标签颜色。图库保留了所有 23 个历史版本，每个版本都可独立预览。这个数字是真实的，因为我在侧栏里数了两遍。但问题在于：版本列表的排序方式是“最新优先”，我找不到按时间正序排列的开关。
这导致我每次想对照最早一版都得滚动到底部。
也许有人觉得这是吹毛求疵，但我认为版本管理的第一原则应该是可预测的排序。图库的设计者似乎更在意“快速回到上一版”，而不是“回顾全部历史”。这不是对错问题，是侧重点问题。我保留自己的看法。
周樱是图书馆数字化部门的协调员，她那天在电话里对我说：“你们的批量导出能不能不要每次只导 20 张？”我解释这不是我们站点的功能，是新奥门17图库本身的限制。她沉默了一下，然后说：“那我只能分十七次点。”这段对话发生在一个周一上午，我清楚地记得电话背景音里有扫描仪的滚轮声。
她后来找到了一个变通办法：用打印预览拼版。
这个限制在官方文档里被称为“安全分片”，每批最多 20 个文件请求。但我认为对于拥有“十七图”这样成组预览设计的图库来说，20 这个数字有些尴尬——你没法一次导完两组。不过，也许设计者考虑的是服务端压力，而非用户习惯。
如果你在新奥门17图库的标签管理页面同时选中两个颜色相近的标签（比如“#青瓷”和“#浅青”），然后按住 Shift 点击“合并”，系统会弹出一个确认框，上面写着“合并后不可撤销，但历史记录保留在审计日志”。这个交互我是在翻阅 2018 年的一篇博客时偶然发现的，博客作者是名为“老何”的独立开发者，他称这个功能为“温和的强制”。
我试了，确实如此。
但“审计日志”入口极其隐蔽，位于个人设置页面的最底部，字号只有 11px。我花了六分钟才找到。这个设计到底是想让用户知道，还是不想让用户知道？我没有答案。我只知道，一个好的功能不该藏得像一个秘密。
吴桐在杭州用一台 2022 年的 MacBook Air 测试了“全库随机抽取十七图”的响应时间，三次平均 0.76 秒；我在合肥用一台 2019 年的 Windows 笔记本做同样的操作，平均 3.2 秒。差距主要出现在缩略图解码环节。这个数据并不严谨，但是我想说明一点：图库的性能报告很少提及硬件基线，用户也就无法判断“慢”到底是产品问题还是设备问题。
我倾向于认为产品应该公布一个最低参考配置。
吴桐倒是乐观，他说“至少随机抽取不会卡死”。我同意，不卡死是底线。但底线之上，我们是否可以要求更多？比如在加载时显示一个进度条，而不是让用户盯着一个旋转的图标猜测它到底有没有在转。
我是江晚，一个喜欢在图库里翻旧图的人。目前在一家地方文献研究所做数字化整理，日常就是和扫描件、元数据、缩略图打交道。这个站是我用业余时间维护的笔记页面，用来记录那些我看到却还没想明白的细节。最近我在反复测试新奥门17图库的“十七图”分组逻辑，试图把它写清楚，但进展缓慢。如果你也有类似的困惑，欢迎一起讨论。
目前最大的问题是：找不到合适的对照样本。
“每批最多十七张——这是设计限制，也是思考的节奏。”