返回列表时的位置恢复是硬要求
别名: 滚动位置恢复 · return to list offset · 无限列表回跳
概念解释
从无限列表点进详情再回来，人期望仍停在刚才那一条，而不是被扔回顶部重新往下翻。滚动位置恢复（scroll restoration）在这种列表上不是锦上添花：没有页码可以当作坐标，位置一旦丢失，找回代价按已经翻过的长度增长。它管的是「离开再回来还在不在原地」，不管有没有终点、也不管页脚在不在。
机制
无限列表的坐标系脆弱。条目没有稳定页号，只有当时的偏移、锚点 id 和已加载窗口。进入详情通常会卸载或虚拟化掉列表，回来时若只重建第一页，锚点就不在 DOM 里，浏览器默认的滚动恢复也会对不上。用户看到的是熟悉的第一屏，以为自己被系统送回了起点，于是放弃继续扫，或愤怒地重新表演刚才那一段滚动。
恢复失败还有时间维。列表在离开期间插入了新项（信息流顶部刷新），按像素恢复会停在错误的对象上；按对象 id 恢复才能说「还是那一条」。已加载窗口若被丢掉，即使记得 id 也要先重新取回从顶部到该 id 的全部中间项，延迟会让人以为恢复没有发生。所以硬要求包含三层：还是那条对象、周围上下文还在、回来时立刻能看见，而不是先闪第一页再跳。
怎么研究
用进出任务：在已经翻过两屏以上的位置打开一项，再返回，测量锚点是否在视口内、偏移误差、以及是否先出现顶部再跳动。自变量是恢复策略（像素 / 对象 id / 不恢复）和离开期间是否插入新项。因变量是「回来仍是那条」的判定、重新滚动的距离、口头愤怒或放弃。
进程被系统回收后的冷启动要单列。会话内失败是缺陷；冷启动至少应恢复到对象 id，允许周围窗口异步补齐。
边界
列表被筛选、排序或登录态改变后，旧锚点可能不在新结果里，恢复到一条已消失的项会变成错误页。这时应回到列表顶部并说明「内容已更新」，而不是卡在空白。用户在详情里完成了删除，回来时该项本就该消失，应落到它的邻项。极长的虚拟列表在低端机上无法在一帧内重建窗口，允许先出骨架再落到锚点，但不能先让人交互顶部再突然拽走。手动下拉刷新是用户主动放弃当前位置。
怎么落地
- 离开列表时记下对象 id、其前后若干条、以及视口内的相对位置；回来先确保该 id 已在已加载窗口里，再滚动到它，而不是先渲染第 1 页。
- 离开期间若顶部插入了新项，按对象恢复，不要按像素；必要时提示「上方有新内容」而不把人拽到顶。
- 锚点已不存在则落到邻项或顶部，并说明原因，避免空白。
- 验证：翻过至少两屏，进入详情，返回。锚点必须立刻在视口内，不允许顶部闪一下。再在离开期间插入新项，回来仍应是同一条。录屏里每一次从顶重新往下翻，都是恢复失败。