前端详情页返回列表丢失滚动位置怎么办：从复现到恢复一步步排查

列表页滚动到第 60 条，点进详情页看了一眼，再点返回，页面却回到了顶部。这个问题看起来不大，但用户会立刻失去刚才的阅读位置，尤其商品列表、文章列表、工单列表都会很影响体验。

这篇文章我们不直接丢一个最终方案，而是像排查线上问题一样走一遍：先复现现象，再猜可能原因，接着用小代码验证，最后把滚动位置稳定恢复回来。

摘要

本文解决的是“详情页返回列表后滚动位置丢失”的前端体验问题。核心思路是：不要只依赖浏览器默认行为，而是在离开列表前记录位置，在列表数据和 DOM 都准备好之后再恢复，并给异步渲染、筛选条件变化、路由缓存做兜底。

适合人群

适合正在做 Vue、React 或普通 JavaScript 列表页的同学。只要项目里有“列表页 -> 详情页 -> 返回列表页”的路径，就可以按本文思路改造。

目录

• 先复现：为什么一返回就到顶部
• 第一轮猜测：浏览器默认恢复是不是没生效
• 继续验证：列表重新渲染才是真正拦路点
• 修复方案：离开前记录，回来后恢复
• 常见坑和最终检查

先复现：为什么一返回就到顶部

我们先把现场搭出来。一个列表页加载 100 条数据，滚到中间后进入详情页，再从详情页返回。理想状态是停在第 60 条附近，实际却经常回到第一条。

这一步要先确认问题不是错觉。可以在列表页离开前打印当前滚动位置，在回来后再打印一次。

window.addEventListener('pagehide', function () {
  console.log('离开列表时 scrollY:', window.scrollY);
});

window.addEventListener('pageshow', function () {
  console.log('回到列表时 scrollY:', window.scrollY);
});

如果离开时是 2600，回来时却是 0，就说明滚动位置确实丢了。此时先不要急着改代码，我们继续看是谁把位置弄没了。

第一轮猜测：浏览器默认恢复是不是没生效

浏览器本身有历史滚动恢复能力。我们第一反应通常是：是不是默认恢复被框架路由、手动跳转或页面刷新打断了？可以先看 `history.scrollRestoration`。

console.log('scrollRestoration:', history.scrollRestoration);

if ('scrollRestoration' in history) {
  history.scrollRestoration = 'manual';
}

这里把恢复交给我们自己处理。原因是现代前端页面常常不是完整页面返回，而是路由组件切换、数据重新请求、虚拟列表重算高度。浏览器尝试恢复的时候，列表内容可能还没出来，它只能把页面停在顶部。

这一步验证后，我们能排除一个误区：问题不一定是浏览器不会记位置，而是它恢复得太早，赶在列表渲染之前完成了。

继续验证：列表重新渲染才是真正拦路点

接着我们把关键变量加上：列表数据是不是回来后重新加载？DOM 高度是不是恢复前还不够？如果列表容器高度只有首屏，恢复到 2600 当然不会成功。

async function loadList() {
  console.log('开始加载列表');
  const rows = await fetchList();
  renderRows(rows);
  console.log('渲染后文档高度:', document.documentElement.scrollHeight);
}

如果日志显示“回到列表时 scrollY: 0”先出现，“渲染后文档高度: 5000”后出现，真正原因就很清楚了：恢复动作发生在列表渲染完成之前。

修复方案：离开前记录，回来后恢复

现在可以动手改。我们需要记录三个信息：路由路径、筛选条件、滚动位置。只记 `scrollY` 不够，因为用户换了关键词或分类后，旧位置可能已经没有意义。

function makeListKey(routePath, query) {
  return 'list-pos:' + routePath + ':' + JSON.stringify(query || {});
}

function saveListPosition(routePath, query) {
  const key = makeListKey(routePath, query);
  sessionStorage.setItem(key, String(window.scrollY));
}

function readListPosition(routePath, query) {
  const key = makeListKey(routePath, query);
  return Number(sessionStorage.getItem(key) || 0);
}

离开列表前保存，回到列表并渲染完成后恢复。这里推荐用一个“渲染完成后再滚动”的小函数，避免请求和 DOM 更新还没结束。

function restoreAfterRender(y) {
  requestAnimationFrame(function () {
    requestAnimationFrame(function () {
      window.scrollTo({ top: y, left: 0, behavior: 'instant' });
    });
  });
}

async function enterListPage(routePath, query) {
  const y = readListPosition(routePath, query);
  const rows = await fetchList(query);
  renderRows(rows);
  restoreAfterRender(y);
}

为什么用了两次 `requestAnimationFrame`？第一次等当前任务后的渲染队列，第二次让浏览器有机会把列表高度真正算出来。实际项目如果有框架生命周期，也可以放在 Vue 的 `nextTick`、React 的布局副作用或列表组件的渲染回调里。

常见坑和最终检查

第一个坑是筛选条件变化后还恢复旧位置。比如用户从“全部文章”切到“前端文章”，此时应该使用新 key，不能拿上一次的滚动位置。

第二个坑是虚拟列表。虚拟列表通常不是直接恢复 `window.scrollY`，而是调用组件提供的滚动方法，例如滚到指定索引或指定偏移量。否则容器内部的位置和页面位置会对不上。

第三个坑是图片或卡片高度后加载。列表项高度如果后续变化，恢复后还可能轻微跳动。可以给封面、卡片、骨架屏设置稳定高度，或者等关键内容完成后再恢复。

function checkRestoreResult(expectedY) {
  const current = window.scrollY;
  const gap = Math.abs(current - expectedY);
  console.log('期望位置:', expectedY, '当前位置:', current, '偏差:', gap);
  return gap 

最后我们再走一遍：滚到第 60 条，进入详情，返回列表，列表加载完成后恢复到接近原位置。如果偏差在一个卡片高度以内，用户基本不会感知到跳动。

总结

详情页返回列表丢失滚动位置，本质上不是单纯“浏览器没记住”，而是前端路由、异步数据和 DOM 高度变化打乱了默认恢复时机。排查时按“复现位置 -> 检查默认恢复 -> 看渲染时序 -> 保存并延后恢复”的顺序走，问题会变得很清楚。

落地时记住三点：离开前保存带条件的 key，回来后等列表渲染完成再恢复，筛选变化和虚拟列表要单独处理。这样用户从详情页返回时，才能自然地回到刚才正在看的地方。