如何通过 history.scrollRestoration 手动控制长页面刷新后是否强制回顶

如何通过 history.scrollRestoration 手动控制长页面刷新后是否强制回顶

先说一个核心结论：history.scrollRestoration = 'manual' 这个设置，其实并不能直接让页面刷新后自动回到顶部。它的作用仅仅是关闭了浏览器自动恢复滚动位置的行为。要想真正实现“刷新后始终在顶部”的效果，必须配合 beforeunload 和 pageshow 这两个事件，手动调用 window.scrollTo(0, 0) 才行。

为什么设成 'manual' 后页面刷新还是没回顶

很多开发者会在这里踩坑：明明设置了 manual，怎么刷新后页面还是停在老地方？问题在于，scrollRestoration 主要管的是通过 history API（比如 history.back()、history.forward()）进行的导航，以及部分特定的刷新场景。对于普通的页面首次加载或者直接按 F5 刷新，它往往无能为力。

尤其是当用户已经向下滚动了一段距离再刷新时，浏览器很可能会从上一次缓存下来的 scrollY 值开始绘制页面。这时候，DOM 已经存在，样式也生效了，但你的 scrollTo(0, 0) 还没来得及执行，结果就是页面要么“卡在中间”，要么先闪现一下旧位置再跳回顶部，体验非常糟糕。

• 其中，beforeunload 事件是唯一能在页面卸载前、无感知地将滚动位置归零的时机，因为此时 DOM 完整，且视觉上不会产生跳动。
• 但要注意，iOS 的 Safari 浏览器对 beforeunload 的支持并不稳定，某些版本下刷新时可能根本不触发。
• 另外，通过 location.reload() 进行的刷新，在缺乏用户交互的上下文中，也可能跳过 beforeunload 事件。
• 如果只依赖 scrollRestoration = 'manual' 加上在 DOMContentLoaded 事件里滚动，那种视觉上的跳动几乎是必然的。

必须同时监听 beforeunload 和 pageshow

要实现可靠的回顶，这两个事件一个都不能少，它们分别解决了不同路径下的“非预期滚动”问题：

• beforeunload：用来捕获所有主动离开页面的行为，比如按 F5、在地址栏回车、或者调用 location.reload()。在这个时刻调用 window.scrollTo(0, 0)，可以确保页面在卸载前，滚动位置就已经归零了。
• pageshow：这个事件专门用来应对浏览器从缓存恢复页面的场景，典型例子就是 iOS 上点击后退按钮，或者 Android 系统杀后台后重建页面。关键是要判断 event.persisted === true，只有在这个条件下，才需要再次执行一次 window.scrollTo(0, 0)。
• 漏掉 pageshow 会怎样？在 iOS 上后退时，页面位置很可能一片混乱。漏掉 beforeunload 呢？普通刷新后，页面大概率会卡在中间。
• 还有个小细节：不要用 window.onbeforeunload = handler 这种赋值方式，容易被其他代码覆盖。统一使用 addEventListener('beforeunload', ...) 来添加监听器更稳妥。

移动端和 overflow: hidden 场景下的特殊处理

当页面设置了 body { overflow-y: hidden } 时（常见于全屏切换、模态弹窗或视差滚动效果），问题会变得更加棘手。如果刷新后滚动位置没有及时归零，内容可能直接被截断，导致白屏或者出现大片空白区域——这可以说是“错位即崩溃”的典型场景了。

• 在这种场景下，beforeunload 事件几乎是唯一能规避视觉跳动的时机，因为它发生在浏览器重绘页面之前。
• 考虑到某些 iOS 版本中 beforeunload 可能失效，建议把 visibilitychange 事件作为兜底方案（监听 document.visibilityState === 'hidden' 的时刻，并执行置顶操作）。
• 要避免在 load 或 DOMContentLoaded 事件中调用 scrollTo，因为此时页面已经渲染出来了，用户会清楚地看到页面滚动的过程。
• 另外，不要单独去设置 document.documentElement.scrollTop = 0，兼容性不好。统一使用 window.scrollTo(0, 0) 是更保险的做法。

常见错误写法与对应现象

下面这些写法看起来似乎有道理，但在多端测试中很容易出问题：

• 只设置 history.scrollRestoration = 'manual'：结果就是刷新后页面仍然停留在旧位置，在 iOS 上尤其明显。
• 只在 DOMContentLoaded 中调用 scrollTo(0, 0)：页面会先闪到底部（或旧位置），再弹回顶部，有明显的视觉跳动。
• 使用 onbeforeunload = () => scrollTo(0, 0)：如果页面存在多个监听器，这种方式容易被覆盖，导致置顶逻辑失效。
• 不判断 pageshow.persisted 就执行 scrollTo：这会导致页面每次显示（show）时都滚回顶部，破坏了用户正常的滚动浏览体验。
• 在虚拟列表等容器上直接调用 scrollTo，而不是在 window 上：如果容器的高度尚未计算完成，滚动操作可能无效或产生偏移。

说到底，真正可靠的强制回顶，不是靠一个属性开关就能搞定的。它依赖于对 beforeunload 和 pageshow 这两个事件时机的精准配合。而其中最容易被忽略的关键，就是 pageshow.persisted 这个布尔值——它明确告诉你，当前页面是从缓存重建的，还是全新打开的，处理逻辑必须区分对待。这才是实现无缝体验的核心所在。