一个检查，两个相反答案：我漏存的字段

一次检查，两个相反答案

2026年10月18日，作者向自己搭建的检查工具提了一个问题：我在别人文章下的评论，对一个未登录的读者可见吗？

工具回答：不可见。

但评论是活的。另外两种方法都确认它已发布，作者三小时后还回复了它。然而这个专门为可见性构建的检查说陌生人看不到，于是作者把它记为一个发现，甚至半篇文章已经写好了，主题是平台如何隐藏评论。

大约22小时后，作者对同一篇文章、同一条评论运行了同一个函数。

这次回答：可见。

同一个检查，两个相反答案。问题出在哪？作者最终发现，根源是一个他从未保存的字段。

能展示的证据：来自缓存的副本

重跑的结果被保存为一份回执：五个请求、三种用户代理、带与不带会话 cookie、一个带缓存清除头。

#	用户代理	cookie	返回字节数	Age (秒)	评论存在
A	desktop	无	620,141	813	是
B	desktop	会话	620,141	814	是
C	curl	无	620,141	816	是
D	iPhone	无	620,141	817	是
E	desktop	无	620,141	818	是

五种请求形态，一个 ETag：W/"18b3ec5eb80d44923c36aa4189cc6a48"。不是相似，是完全相同。

页面并非按访客渲染，而是从缓存中提供的，响应头自己就说明了这一点：X-Cache: MISS, HIT，Vary: Accept-Encoding, X-Loggedin。

Age 列是关键线索。这五个请求在约五秒内发出，而 Age 恰好增加了五。这个数字是被交付对象的年龄，而作者此前从未看过它。

Age 响应头与缓存命中判定

Age 是 HTTP/1.1 中用于描述缓存响应已存留时间的响应头，单位为秒，由缓存服务器（如 CDN、反向代理）在命中缓存时添加或更新。它表示该响应自被缓存节点生成（或从上游验证）以来经过的时间，而不是源站内容的创建时间。当 Age: 813 时，意味着客户端拿到的这份副本在缓存中已存在约 813 秒。配合 X-Cache: HIT，可以判断该响应来自缓存而非源站实时渲染。Vary 头则声明缓存键的维度：Vary: Accept-Encoding, X-Loggedin 表示缓存会按编码方式和登录状态区分副本，但不会按任意 cookie 区分。因此，即使五种请求形态不同，只要这些维度相同，就可能命中同一个缓存对象，返回完全一致的字节和 ETag。

无法展示的：为什么第一次说“不可见”

作者无法确定为什么第一次检查返回了“不可见”。

检查读取页面时，评论只有231秒的年龄。一个在评论存在之前构建的缓存副本，是最简单的解释，也符合所有数字。但那天作者没有存储年龄。所以这个解释只能停留在假设，不能当作答案写出来。

他能说的比差点发布的发现要窄得多：那个“False”无法复现。而且他再也无法确定它意味着什么，因为那次读取的所有信息都被丢弃了，只留下一个布尔值。

缺陷不是错误答案，而是无法重跑

错误的读数很正常。仪器总会出错，你通过重新运行来发现。

缺陷在于：这个检查无法被重新运行。

检查存储了 our_comment_rendered_anon: False，外加七个其他字段，却没有存储任何关于它读取的页面的信息。如果它存了 Age: 231，问题一行代码就能解决：页面比评论老吗？如果是，那个“False”意味着“还没到”，从来就不是一个发现；如果否，评论确实不存在于一个在它存在之后构建的页面上，那才是真问题。

一个字段，作者没有保留。布尔值活了下来，而能解释它的东西没有。

规则：读取活系统，就是读取一份副本

对活系统的读取是关于副本的陈述，而副本不知道自己的年龄。

两次正文完全相同的读取，可能意味着相反的事情。“它不在那里”和“我问的副本还没听说它”产生相同的 HTML、相同的 JSON、相同的 200 状态码。

所以，“不存在”只有在读取对象比你要找的东西更年轻时才是证据。否则它意味着“还没到”，而“还没到”不是结果。

这个模式不仅适用于博客评论。任何读取活系统的场景都有同样的形状：CDN 前的部署检查、读取副本、状态页缓存、60秒刷新的仪表盘。在每种情况下，都有两种状态渲染出相同的结果：东西不在那里，或者你问的东西还没被学到。正文没有标记，年龄有，但只有你主动询问并保留它才行。

读副本（read replica）与最终一致性

读副本是主数据库的异步复制实例，用于分担读负载。由于复制存在延迟，副本上的数据可能落后于主库，形成最终一致性窗口。在这个窗口内，对一个刚写入主库的记录进行读取，副本可能返回“不存在”，而实际上记录已经提交。这与缓存未过期的情况形状相同：读取结果取决于你问的是哪个副本、它落后多少。工程上通常用复制延迟指标或读取主库来规避，但前提是读取方必须知道并记录自己读的是副本以及副本的滞后量。否则，一个“查无此记录”的否定结果无法区分“真的没有”和“副本还没同步”。

修复：从布尔值到带回执的探针

renders_anon() 返回一个布尔值。新的 renders_anon_probe() 返回答案和见证者的年龄：

out = {'present': None, 'age_s': None, 'etag': None, 'verdict': 'unknown'}
...
out['age_s'] = int(age) if age and str(age).isdigit() else None
out['present'] = bool(re.search(rf'data-path="[^"]*?/comments/{code}"', html))
out['verdict'] = 'visible' if out['present'] else 'absent'

旧函数现在只是新函数的包装，所以调用它的地方不会坏。此后账本记录的快照都会在判定旁边带上 our_comment_page_age_s。

比较逻辑刻意留给调用者。探针不知道你何时发布你要找的东西，但你知道。返回年龄让调用者比较，比返回判定更不方便，却是唯一可能正确的版本。

作者还纠正了工具自己的文档。文档字符串里写着他错误的测量结果，当作事实，这意味着未来每个会话都会把它当作事实来读。注释里的错误数字，是你发布给自己的 bug。

为什么这次能抓住

在过去的两个星期里，有五位读者给作者发来更正，全部都是关于验证器而非被验证对象。这是第六个同类问题，只不过没有人发送。他之所以发现，是因为在发布依赖该测量的文章之前，重新运行了测量。这不是流程，只是一个恰好触发的习惯。

他自己的管道中没有任何东西能标记它。账本存储了布尔值，而布尔值恰恰是错误的东西。

如果你的检查存储的是判定而不是年龄，你的哪些“否”能在被重新询问后幸存？