从 6 月 12 日晚上 21 点 47 分发现第一张缩略图裂开，到今天上午 10 点 12 分全部索引重排完毕，我用了三十六个小时，也只弄懂了其中一半的原因。
6 月 12 日晚上九点四十七分，我在翻自己三年前拍的一张照片——南京汉中门大街的梧桐，逆光，叶子边缘烧成金色。缩略图加载到一半停住，左上角占了一小块灰白的裂图符号。
第一反应是网络。刷新，没用。第二反应是那只老旧的 NAS 又掉了盘，登录上去，磁盘健康度 98%，风扇转速 1120 转，一切正常。第三反应才是图库本身。
我打开后台的索引面板，看到 4,271 张图片的元数据里，有 316 条记录的 cached_at 字段停在 2026-05-28 03:14，之后再没被更新过。也就是说，索引器在那天凌晨停摆了一次，之后只是勉强维持着一个过期的名单。
索引器不是坏了，是它以为自己没坏。这是整件事里最麻烦的部分——它每十分钟跑一次，每次都返回 status: ok。
那天晚上我给它加了一段检查：让它每次跑完，随机抽 20 条记录回源比对。第二天早上七点，抽样结果出来了，20 条里 6 条对不上。问题这才被真正承认。
顺手记一笔，之前排查反向代理跳转异常时留下的经验在 444447.cm浏览器 那篇里，脚本复用了同一套逻辑。
按发生顺序排列，每条都对应一个能被查证的物、事或人。
2023 年 11 月拍的，原图 42 MB。它裂开的那一瞬间，我才意识到缩略图和原文件是两条独立链路。
索引器最后一次成功写入的时间戳。没有报警，没有日志异常，像一次无声的自杀。
占总数的 7.4%。我一条条数了两遍，第二遍确认不是自己眼花。
他说：「状态码健康不等于数据健康。」我当时想反驳，后来发现他说得对。
每次跑完抽 20 条，回源读真实文件头，比对哈希。简单粗暴，但立刻暴露了问题。
全部索引重排耗时 11 分 38 秒，比预估的 8 分钟慢。慢在磁盘随机读。
回源修好之后，边缘节点还在吐旧图。清了 3 个区域，花了 40 分钟才一致。
最后一条索引写入完成。我在终端里敲了 date，屏幕上就是这六个数字。
监控只看了进程存活和返回码。这是设计上的盲区，至今没想好怎么补。
翻到第三章，作者说「信噪比高的监控才会被信任」。我盯着这句话看了很久。
我是江晚，一个人维护这个站，主要写图片档案、索引系统和数字保存相关的东西。
白天在出版社做数字化校对，晚上回来继续跟自己的图库较劲，已经第七年。
做这个站的原因很朴素：我想把每次修东西的过程写下来，因为网上大部分教程只告诉你「怎么做」，不告诉你「为什么当时没想到」。
我写作状态不好的时候就读旧笔记，今天是第 43 篇，还是有一半问题没答案。
状态码健康不等于数据健康；监控若只报告「我还在」，它就什么也没报告。—— 舍弗勒《数据质量工程》第三章，2021 年，第 87 页