RFC 8767的第 7 节说：
因为现代解析器使用预取和请求合并等技术来提高效率，所以不必在存在陈旧数据的情况下每个客户端请求都需要触发新的查找流，而是最近已经做出了善意的努力来刷新过时的数据在交付给任何客户端之前。
我没有得到这个建议的限制。假设我的缓存中有“abc.com”，其 TTL 为 1 小时并已过期 30 分钟，而“xyz.com”的 TTL 为 1 小时并已过期 20 分钟。如果我将陈旧数据保留 12 小时，我应该先提供陈旧数据（因为它不久前已过期）还是应该先尝试刷新？
在文档中，它说如果客户端计时器过期（约 1.8 秒），则可以提供陈旧数据，但现在建议在某些情况下返回第一个陈旧数据。但我不明白这些情况是什么。
而是最近做出了善意的努力来刷新过时的数据
这是否意味着如果解析器在 TTL 过期之前至少尝试刷新数据一次，我可以立即服务器陈旧数据？现在可以成功刷新任何请求吗？
您引用的文本是在此上下文中（紧接在您的文本之前）：
这意味着只有当解析器在“客户端响应计时器”触发之前无法获取新数据时（这是建议的 1.8s 相关的地方，在本文前面），才允许提供陈旧数据（使用缩短的 TTL）。
这也不意味着它停止处理此查找只是因为它向客户端提供了陈旧的数据。它仍应尝试完成查找并为将来更新缓存，以避免下次提供过时的数据。
如果查找不仅比“客户端响应计时器”（建议 1.8 秒）慢，而且比“查询解析计时器”（查询的最大时间，建议 10-30 秒）慢，甚至完全不可能，那么它建议只需要每隔“故障复查定时器”秒（建议30s）再次尝试查询。
即，如果您尝试在过去 30 秒内刷新（或使用任何失败重新检查计时器）并且该尝试完全失败（或可能仍在进行中），那么您可以提供陈旧的数据。否则没有。
您应该将其视为不提供过时数据的目标。RFC8767 所说的本质上是，当传统行为是超时（从客户端的角度来看）或由于无法获取当前数据而返回错误时，您可以在继续时暂时提供陈旧数据尝试获取当前数据。
来自第 5 节。示例方法：