49图库来源标注上线：同步时刻可逐条核对

2026 年 10 月 17 日，49图库 发布 3.5.8，为归档里的每一条记录补上两个字段：数据来源与同步时刻。此前页面只在顶部显示一次「更新于」，具体某一期是什么时候进的库、取自哪个公开数据源，用户看不到。新版把这信息落到每行：8,912,470 条历史记录在 12.6 小时内完成回填，抽样 1,284 条与原始记录逐字比对，差异为 0。

提出这个需求的不是团队内部，而是一份份对账表。过去半年里，客服收到的问询中有 214 条与「这条记录是不是最新的」有关，其中 86 条发生在数据源公布后的一分钟内。可见问题不在数据本身，而在用户无法自证手上的数字是哪一刻的。3.5.8 要解决的，就是这个「自证」问题。

为什么每行都要有时间戳

记录同步是一条链：数据源公布、同步服务接收、写入归档库、增量索引更新、查询缓存失效。任何一环出现延迟，页面上的数字都会慢一拍，而顶部那一个「更新于」只代表最后一次成功同步的时间，无法说明具体某期是否迟到。把时间戳下沉到记录级之后，判断依据变成「这一期的同步时刻」与「数据源公布时刻」的差值，不再依赖全局状态。

3.5.8 之后，详情页在号码下方固定展示三行：来源名称、公布时刻、同步时刻。三行都精确到秒，格式统一为 2026-10-17 21:32:18。导出文件也带上这两列，字段名为「同步时间」与「数据来源」，默认勾选，取消勾选需要两步确认，避免有人导出后无法回溯。

891 万条回填：12.6 小时与 0 差异

回填按年份从近到远分批执行，每批 20 万条，批间留 3 分钟冷却，避免影响在线查询。整轮耗时 12.6 小时，其中 2026 年数据 1.4 小时、2025 年 1.6 小时、2024 年及以前 9.6 小时。回填期间查询接口的 P95 从 121 毫秒升到 148 毫秒，结束后回落，未出现超时失败。

校验环节做了两件事：一是抽样比对号码与公布日期，1,284 条全部一致；二是核对时间戳的合理性，检查是否存在同步时刻早于公布时刻的异常，结果 0 条。另外发现 3 条记录的公布日期与相邻期号顺序不符，属于数据源本身的补录，团队保留了原值并在来源字段里标注「补录」，不做自动修正。这类记录占全部归档的 0.0004%。

同步延迟本身也做了统计：2026 年 9 月 1 日至 10 月 15 日的 45 期记录中，从公布到可查的中位延迟为 14 秒，P95 为 21 秒，最长一次 38 秒，原因是数据源当日临时改版导致解析重试两次。这几个数字现在写在每期的详情页里，用户不必再靠猜。

时间戳应该怎么读

看两个值就够了：公布时刻与同步时刻的差值，正常在 18 秒以内；若超过 60 秒，说明当期曾重试。第二个值是「最近同步」，它代表同步服务最后一次成功运行的时间，与单期时间戳不是一回事。团队在页面上把两者分开显示，并在帮助文案里写明区别，避免把「今天没有新一期」误读成「同步停了」。

移动端的离线缓存同样带时间戳。由于离线数据不重新校验，界面会额外显示「离线副本」标识，并给出该副本的最近同步时间；联网后两秒内自动补齐，标识随之消失。这一点在 3.5.8 之前没有明确区分，曾让用户在断网状态下误以为查的是最新一期。

接下来团队会把来源字段扩展到统计视图：走势图上每个节点都可以点开看到样本区间内各期的时间戳分布，便于判断某段数据是否存在同步空档。相关改动已在内部测试，预计随 3.6 系列后续版本推送。

3.5.8 已全量推送，网页端与客户端同时生效。想查看某期的时间戳，可以在 下载客户端 后输入七位期号，详情页第三屏即为来源信息区；网页端的位置与客户端一致。