简答： 造成这种情况的原因有两个：缓存（重复查询可能会返回已存储的结果）以及 服务器的临时性状况（某种暂时性的unknown在后续尝试中可能解析为有效结果）。强制刷新请求始终会执行一次新的实时检查。
缓存
为确保验证过程快速高效，并避免对邮件服务器造成过大压力，已确认的验证结果将被缓存约24小时。如果您在该时段内再次验证同一地址，可能会收到缓存的结果，而非全新的实时核查结果，并且不会因此被重复收费。这使得重复查找始终保持即时性。
一个例外：unknown 的结果不会被缓存。 由于“我们无法确认这一点”是一种临时性答复，因此对某个 unknown 地址的重新检查始终会执行一次全新的实时验证——这也正是为什么在后续尝试中，unknown 可能会转变为确定性结果的原因。
要强制进行一次全新的实时验证并忽略缓存，请使用 force_refresh=true 发送请求。强制刷新会执行一次真正的检查，并根据其新的检查结果进行计费。
瞬态条件
一些较早的unknown结果是由接收端的临时性状况引起的：
- 灰名单机制——服务器会故意延迟首次尝试，并接受后续的再次尝试。
- 限速——提供商当时正在对流量进行节流。
- 超时——服务器曾短暂出现响应缓慢或无法访问的情况。
当您稍后再次检查时，这些状况可能已消失，因此先前的unknown可能会变为确定的valid或invalid。这是预期的行为，而非不一致。
我们的建议
- 如需获得权威且实时的解答，请使用**
force_refresh=true**。 - 如果您正在对列表进行批量验证，则无需对每个地址都强制刷新——在缓存的有效期内，缓存结果依然准确可靠，并且可以为您节省验证额度。
- 重试后，结果从
unknown变为确定状态，这是一个好迹象：这意味着临时性问题已消除，我们得到了一个真实的结果。