移动端长列表回到顶部失效：scrollIntoView 与虚拟滚动的定位冲突

线上活动页的商品列表接入虚拟滚动后，用户从详情页返回，点击“回到顶部”却只移动了一小段。问题只在手机端明显：普通短列表正常，快速滑动、切换筛选条件后更容易复现。最后发现，scrollIntoView() 调用时，虚拟列表还没有把目标节点放回 DOM，浏览器测到的是旧布局。

用户看到的不是“滚动失效”，而是滚动到了旧坐标

复现步骤很固定：打开长列表，快速滑到中段，改一次筛选条件，立刻点击顶部按钮。按钮事件确实触发，容器的 scrollTop 也发生了变化，但视觉上距离顶部仍有几十行内容。把列表改回普通渲染后，问题消失。

这说明点击事件和浏览器滚动能力都还在，异常集中在“虚拟窗口重排”和“定位计算”之间。先不要给按钮加更多延时，应该先把一次点击拆成可观察的时间线。

一次点击里实际发生了四个阶段

假设列表容器是 .feed-viewport，虚拟列表根据 scrollTop 只保留可见行。点击按钮后，常见顺序如下：

1. 事件处理器更新筛选条件或目标索引。
2. 框架提交状态，虚拟列表计算新的起止索引。
3. DOM 节点被复用、插入或移除，浏览器等待下一次布局。
4. scrollIntoView() 读取目标节点的当前位置并执行滚动。

如果第 4 步跑在第 2、3 步之前，目标元素可能还代表上一次渲染的行；如果目标行尚未挂载，调用甚至找不到正确节点。移动端高频手势会让这个窗口更容易暴露。

用日志确认根因，而不是盯着按钮猜

在容器、虚拟列表和按钮三处记录同一轮操作的编号，重点看目标节点是否存在，以及调用前后的坐标：

const viewport = document.querySelector('.feed-viewport');

function traceScroll(label, target) {
  console.log(label, {
    scrollTop: viewport.scrollTop,
    targetExists: Boolean(target),
    targetTop: target?.getBoundingClientRect().top,
    viewportTop: viewport.getBoundingClientRect().top
  });
}

function backToTop() {
  const target = document.querySelector('[data-row-index="0"]');
  traceScroll('before scroll', target);
  viewport.scrollTo({ top: 0, behavior: 'smooth' });
  requestAnimationFrame(() => traceScroll('after frame', target));
}

如果日志显示 scrollTop 已经变成 0，但下一帧又被虚拟列表改回较大值，说明列表的滚动监听在根据旧的可见索引回写位置。若目标节点为空，则是挂载时机问题，不能用一个更大的滚动距离掩盖。

修复方案：让容器成为唯一滚动真相

“回到顶部”不需要依赖第 0 行是否存在。对容器直接滚动，并把动作放到筛选状态和虚拟窗口完成之后；如果业务确实要定位某一行，再先让虚拟列表滚到目标索引，等待节点出现后做一次精确校准。

let scrollRequest = 0;

function stableBackToTop() {
  const requestId = ++scrollRequest;
  viewport.scrollTo({ top: 0, behavior: 'auto' });

  requestAnimationFrame(() => {
    if (requestId !== scrollRequest) return;
    viewport.scrollTo({ top: 0, behavior: 'smooth' });
  });
}

这里连续安排两次定位不是为了“碰运气”。第一次清掉当前滚动状态，下一帧再确认虚拟列表没有回写旧位置。筛选操作则应在数据更新完成的回调中调用 stableBackToTop()，不要在设置状态的同一行后立刻调用。

三个容易留下隐患的“看似修好”

把 setTimeout 写成固定 300 毫秒

网络响应、设备性能和动画帧率都不固定，固定时间可能在快设备上浪费等待，在慢设备上仍然早于布局。优先使用框架的更新完成时机和 requestAnimationFrame，必要时观察目标节点是否真实存在。

只给目标行加 scrollIntoView

虚拟列表的目标行可能暂时不在 DOM 中。定位索引和定位 DOM 节点是两件事：前者交给虚拟列表，后者只能在节点挂载后执行。

只测一次点击

至少连续覆盖快速滑动后点击、筛选后点击、返回页面后点击、键盘触发和减少动画设置。尤其要确认滚动容器没有因为页面恢复逻辑再次被写回旧值。

上线前的回归结果应该具体到状态

把“能回到顶部”拆成可验收的结果：点击后容器的 scrollTop 为 0；下一帧仍为 0；筛选结果的第一条记录可见；快速连续点击不会产生旧请求覆盖新请求；用户开启减少动画后不强制播放平滑滚动。

如果列表有吸顶筛选栏，还要区分容器顶部和页面顶部：前者由 viewport.scrollTo 负责，后者才使用窗口滚动。职责分开后，虚拟滚动只维护可见窗口，按钮只改变明确的滚动容器，问题就不再靠延时参数维持。

相关问题

为什么普通列表没有这个问题？

普通列表通常一直保留目标节点，浏览器可以立即读取稳定的布局；虚拟列表会复用节点并延迟重排，所以时序差异更明显。

什么时候仍然适合使用 scrollIntoView？

当目标元素确定已经挂载，并且滚动容器清晰时可以使用。对虚拟列表，应先完成索引定位，再在节点出现后调用它。

平滑滚动会不会放大问题？

会。动画期间虚拟列表仍可能响应滚动事件并更新窗口。先用即时滚动确认坐标稳定，再按用户的减少动画偏好决定是否启用平滑效果。

这类问题的关键不是给滚动按钮增加更多代码，而是确认“谁拥有滚动位置、何时布局稳定、目标是否真的存在”。先记录时间线，再把容器滚动和虚拟索引定位拆开，移动端长列表的回到顶部功能才有可重复的验收标准。