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

设为'manual'仅禁用浏览器自动恢复滚动，不强制回顶；需同时监听beforeunload（卸载前置顶）和pageshow（缓存页重建时判断persisted再置顶）才能可靠实现刷新后始终在顶部。

history.scrollRestoration = 'manual' 本身不强制回顶，只关掉浏览器自动恢复滚动位置的行为；要真正实现“刷新后始终在顶部”，必须搭配 beforeunload 和 pageshow 事件手动调用 window.scrollTo(0, 0)。

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

因为 scrollRestoration = 'manual' 的作用仅限于 history 导航（如 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 → 容器高度未计算完成，滚动无效或偏移

真正可靠的回顶，不是靠一个属性开关，而是靠两个事件时机的精准配合；最容易被忽略的是 pageshow.persisted 这个布尔值——它决定了你是在“重建缓存页”，还是在“打开全新页”，处理逻辑必须区分对待。