如何通过 history.scrollRestoration 手动控制单页应用在页面刷新后是否保持滚动位置
先说一个核心判断：直接设置 history.scrollRestoration = 'manual' 来实现“刷新后保持滚动位置”，这个思路本身就走反了。 这个操作恰恰是关掉了浏览器的自动记忆功能。想在单页应用（SPA）里实现刷新后精准“回到过去”，你得绕开默认逻辑，自己动手——存下来、读出来、再滚过去。
为什么 history.scrollRestoration = 'manual' 不适合“保持滚动”场景
这个属性其实只有两个选项：'auto'（默认，浏览器帮你记和恢复）和 'manual'（彻底不管，每次都从顶部开始）。一旦你设成 'manual'，浏览器就“摆烂”了，连滚动位置都懒得记，无论是history.back()还是页面刷新，结果都是回到原点。所以，它解决的是“我不想滚到底部”的问题，而不是“我想滚回老地方”的需求。
history.scrollRestoration本质上是个历史状态的全局开关，只控制浏览器原生的恢复行为，它本身不提供让你读取或写入具体位置的能力。- SPA刷新时，整个页面会重新加载，
history.state通常会被清空，你根本没法从里面捞出之前的滚动位置。 - 退一步讲，就算你在跳转前用
history.pushState()手动存了位置，刷新后这个 state 也不会自动触发滚动恢复，逻辑还是断的。
真正可行的方案：用 localStorage 主动存取 window.scrollY
这才是目前业界最稳定、兼容性最好，也是SPA场景下事实上的标准做法。整个方案的关键，其实不在于“怎么存”，而在于“什么时候存”和“什么时候取”，以及如何做好清理。
- 存，要找准时机：在用户即将离开当前路由时保存。可以监听
beforeunload事件，或者在路由守卫里（比如 Vue Router 的router.beforeEach）更可靠地调用localStorage.setItem('scrollPosition', String(window.scrollY))。 - 取，要等DOM就绪：在新页面加载完成后恢复。在
DOMContentLoaded事件或框架的生命周期钩子（如 Vue 的mounted、React 的useEffect）中，读取存储的值，然后执行window.scrollTo({ top: parseInt(pos), beha vior: 'auto' })。 - 清理，要及时彻底：恢复滚动后，务必立刻执行
localStorage.removeItem('scrollPosition')。这一步至关重要，能避免位置信息污染其他页面——比如从一篇长文章页面跳转到首页，首页可不需要继承文章页的滚动深度。 - 移动端，要有兜底方案：注意，
beforeunload在 iOS Safari 上可能不灵光，建议配合visibilitychange事件作为备份方案。
容易踩的坑：行为不一致、视觉闪动、逻辑重复触发
很多实现Demo里跑得好好的，一上线就出怪事：“页面先闪到底部再弹回来”、“点返回键位置乱了套”、“iOS上完全没反应”。这些问题，多半是下面这几个细节没处理好。
- 没指定滚动行为：
scrollTo时如果没加beha vior: 'auto'，Chrome等浏览器会默认使用平滑滚动（smooth），这可能引发额外的布局计算和视觉闪动。对于SPA刷新恢复，必须使用'auto'瞬间定位。 - 恢复时机太早：DOM还没渲染完就急吼吼地执行
scrollTo，结果滚到了一个不存在的偏移量。一定要等到document.readyState === 'complete'或框架确认组件已挂载（如onMounted）后再操作。 - 存储键名冲突：所有页面都用同一个
'scrollPosition'键名，A页面滚到1200px后跳去B页面，B页面刷新后却试图滚到1200px——这显然不对。应该按路由路径生成唯一键名，例如`scroll-${location.pathname}`。 - 第三方脚本干扰：页面里的广告或统计脚本，有时会在 onload 后强行执行
scrollTo(0,0)，覆盖你的恢复逻辑。一个实用的技巧是，把你的恢复代码用setTimeout(() => {...}, 100)包裹一下，错峰执行。
说到底，技术难点不在于调用那几个API，而在于让“存”与“取”的逻辑，和你应用的路由生命周期严丝合缝地对接起来。尤其是在服务端渲染（SSR）加客户端注水（hydration）的复杂场景下，服务端没有 window 对象，客户端首次渲染时DOM状态又不确定，处理好这些边界情况，远比单纯写对方法调用要花更多心思。
