公开事件已经恢复，为什么长期记录还要保留恢复后的观察窗口

公开状态页转为“已恢复”后，一台设备马上可用，另一台仍停在旧错误。两边都可能是真实观察：状态页描述的是发布者掌握的事件与组件，本地设备经历的还包括解析、连接、缓存和应用状态。

公开事件、缓存新鲜度、条件验证、DNS与既有连接各有自己的恢复时点，端到端任务恢复可能晚于状态页转绿。长期记录不应在第一个绿色图标或第一个成功请求出现时立即结束。

状态页的恢复时点不是每台设备的刷新命令

公开状态通常按组件、地区或事件范围发布。它能回答“发布者认定哪一部分何时恢复”，却不知道某台手机是否仍保留旧页面、某个浏览器是否复用连接，或家庭网络是否还在使用先前解析结果。

第一个成功请求只能证明那次路径可用，不能证明所有组件、地区、缓存层与设备都已恢复。反过来，单台设备继续失败也不能推翻公开状态；它可能落在不同地区、不同组件或本地状态中。

事件日志应同时写下公开恢复时间、组件名称、设备、网络、任务和实际完成时间。两条时间线并排，才能看见差距发生在哪里。

仍新鲜的缓存不会因为上游恢复自动消失

RFC 9111 允许缓存直接复用仍新鲜的已存响应，因此源站恢复不等于每台设备立即重新取源。缓存的目标本来就是减少重复传输；若响应仍在新鲜期内，客户端或中间层可以不联系源站。

当响应变陈旧后，缓存可能发送条件请求验证副本。验证成功后可以更新元数据或取得新内容；验证失败、网络不可达或响应允许陈旧复用时，不同层的表现仍可能不同。这就解释了为什么两台设备在几分钟内看到不同内容，而不必立刻假设新的故障。

no-cache、no-store 与 must-revalidate 的作用不同：验证、禁止存储和限制陈旧复用不能互换。no-cache 不是“从不缓存”，而是复用前要验证；no-store 指示不要存储；must-revalidate 则限制陈旧响应在未经成功验证时被使用。即使后来看到这些指令，也不能反推过去所有缓存副本已经被清除。

Cloudflare 的官方缓存文件给出一个实现例子。must-revalidate 要求陈旧后成功验证；stale-while-revalidate 可以在限定时间返回陈旧内容并后台更新。这个例子说明缓存层可能有不同恢复节奏，但不能用来猜测目标服务一定采用相同配置。

分段计时判断本地停在哪一层

W3C Resource Timing 将域名解析、建立连接、发出请求、收到首字节和响应结束分别记录。浏览器可能因跨源限制不显示全部字段，普通用户仍可记录三个可见阶段：点击后是否很快开始、开始后是否持续传输、最后是否真正完成任务。

若失败发生在连接前，解析或网络路径值得继续观察；若连接建立但首字节迟迟不来，远端组件或中间层响应仍是候选；若很快收到内容却仍显示旧状态，缓存或应用内部状态更值得对照。阶段只是缩小范围，不是自动归因。

同一时点比较原设备原会话与新连接对照，再比较正常请求与可确认的重新验证请求，观察差异停在连接前还是首字节后。不要通过关闭安全检查或反复清空所有资料来制造“成功”，否则新的会话、缓存和权限变化又混在一起。

给恢复过程留出三个固定窗口

从公开恢复时点起设置三个观察窗，例如立即、十五分钟后、三十分钟后。窗口长度应按任务特点调整，重要的是固定，而不是事后挑选。每个窗口使用同一设备、同一网络和同一任务，记录成功、失败、首字节等待、内容版本和错误原文。

若原设备失败、新连接成功，保留两者而不要删除慢样本；若所有窗口都失败，而公开状态只覆盖另一个组件，应先核对范围；若连续完成后又复发，事件日志继续延长，不要把中间一次成功当终点。

从公开恢复时点起连续记录三个固定窗口，只有同一任务连续完成并且错误不再复现，才结束本次事件日志。这项规则把“恢复”从一个颜色变成可复查的任务结果。

年龄、新鲜度与验证是三步，不是一句“有缓存”

RFC 9111 的判断顺序先计算已存响应的当前年龄，再和新鲜度寿命比较。仍新鲜时可以直接复用；变陈旧后，缓存再看请求与响应指令，决定验证、拒绝复用或在允许范围内返回陈旧内容。因此“本机有缓存”本身还不足以解释结果，至少要知道副本是否仍新鲜、是否发起验证、验证是否成功。

年龄也不只是从本机保存那一刻开始。响应可能已经经过共享缓存，Age 等信息会参与当前年龄计算。两个设备若在不同时间取得副本，或从不同中间层取回，即使之后同时点击，也可能处于不同的新鲜度阶段。

记录表不需要手算协议公式，但要保留可见迹象：响应时间、内容版本、是否出现 304 或重新下载、Age 是否变化、首次成功后是否再次回旧。看不到这些字段时就写“未知”，不要把未知补成“已清缓存”。

把观察窗口和任务风险配对

短文本页面可以使用较密集的立即、五分钟、十五分钟窗口；大型下载或长连接任务则要留出完整传输周期。窗口不是越长越好，而是要让每次测试能够完成同一任务。只测到连接成功却没有走到任务结束，会高估恢复。

每个窗口保留原会话和新连接两列。原会话继续失败、新连接连续成功，说明连接复用或本地状态值得检查；两列都在首字节前失败，且另一网络正常，路径条件更值得观察；两列都返回旧内容但传输很快，缓存时间线更有解释力。

不要用无痕窗口当作“绝对无缓存”证明。它通常建立新的浏览上下文，却仍可能经过共享缓存、DNS 缓存或 CDN。正确写法是“新浏览上下文对照”，而不是“完全绕过所有缓存”。

连续成功也要定义一致

一次页面打开、一次接口返回和一次完整业务任务不是同一成功标准。事件开始前先写明终点：例如页面可操作、文件校验完成或连接保持十分钟。恢复后仍使用同一个终点，才不会因为想结束记录而降低标准。

如果三个观察窗都连续完成同一终点，可以把事件记为“在本设备与本网络的观察范围内恢复”；若另一设备仍失败，分开写设备结果。长期记录的价值正是保存这种不一致，而不是强迫所有现场在同一时刻得到一个结论。

区分内容恢复、连接恢复与业务恢复

页面能返回 HTTP 成功状态，只说明请求取得响应；内容是否已经更新、登录会话是否可用、文件是否完整仍是另外三项。观察表应把状态码、可见版本、会话结果和最终任务分列。这样就不会把“页面打开了”提前写成“服务完全恢复”。

若响应很快但版本仍旧，先观察缓存年龄与验证；若版本已新但登录失败，事件可能停在会话或身份组件；若登录正常而大型任务中断，持续传输或后台处理仍未走完。每一列只支持本列结论，不把一项成功扩展成全链成功。

用失败样本校准窗口，而不是只保留成功

长期记录最有价值的往往是恢复边缘的失败。保留错误原文、发生时间、请求阶段和随后恢复的时点，可以计算“公告恢复到本地任务恢复”的观察差，而不是事后凭感觉写几分钟。

若失败只出现在一个窗口，下一窗口连续成功，日志写成“短暂残留，原因未定”；若固定间隔反复成功与失败交替，应延长窗口并记录周期，不要平均成一个看似稳定的百分比。若同一错误跨网络和设备持续出现，再提交给支持方，仍避免把它直接归因于缓存。

时间线需要统一时区

状态页可能使用 UTC，设备日志可能使用本地时间。抄录时同时保存原始时间与换算后的本地时间，并注明设备时钟是否自动同步。几分钟的时区或时钟误差足以颠倒“公告先恢复还是设备先成功”的顺序。

时间统一后，再计算每个观察窗相对恢复公告的偏移，例如 +0、+15、+30 分钟。这个相对偏移比散落的钟表时间更适合跨设备比较，也能防止换算错误被误写成缓存延迟。

最后给每条记录加上证据等级：公开公告是外部范围证据，响应头与计时是请求证据，任务完成是用户结果证据。三者一致时可以缩短说明；三者冲突时保留冲突，不用较高等级覆盖较低等级。这样下一位查看日志的人能分清哪些是来源事实，哪些只是现场推论。

结论仍要停在证据边界：公开状态不能替代本地观察，本地日志也不能替代服务方内部监控。本文不对未公开故障、节点或运营商作归因，只说明怎样让恢复后的记录足以交接和复查。

资料来源

• IETF / RFC Editor：《RFC 9111: HTTP Caching》，发布或更新于 2022-06-01
• 万维网联盟（W3C）：《Resource Timing》，发布或更新于 2026-04-20