为什么移动端的scrollTop总是"不准"
先看一个常见的现象：在移动端页面上监听scroll事件，手指快速滑动屏幕时，scroll事件回调里读取document.documentElement.scrollTop，拿到的值明显滞后于视觉上的滚动位置。松手之后页面继续惯性滚动一段距离，这段距离里scroll事件的触发频率也很不稳定，有时甚至长时间不触发。如果你在回调里做了"滚动到某位置就吸顶"的判断，就会看到导航条明显抖动或者延迟才吸顶。
这个问题的根源在于移动端浏览器的滚动模型。iOS的Safari采用惯性滚动，滚动由触摸驱动，整个滚动过程发生在合成器线程上，而JavaScript运行在主线程。当主线程忙于执行其他脚本时，scroll事件会被排队延迟派发，此时你读到的scrollTop已经是几十毫秒甚至几百毫秒之前的快照。Android上的Chrome情况类似，虽然scroll事件触发相对规律，但在低性能设备上依然存在明显的取值滞后。
更隐蔽的一个坑是iOS Safari在滚动进行中读取scrollTop的行为。在某些版本上，惯性滚动阶段读取到的滚动值可能停留在某个中间状态，等滚动完全停止后才跳变到最终值。如果你的逻辑是"滚动超过300像素隐藏返回顶部按钮"，用户快速上滑后按钮可能迟迟不消失，就是这个原因造成的。
基于触摸事件的主动滚动检测方案
既然被动监听scroll事件不可靠，一个有效的思路是反过来主动追踪触摸行为：通过touchstart记录初始位置，touchmove中实时计算偏移量，touchend后结合最后的移动速度估算惯性滚动区间。这种方式不依赖浏览器派发scroll事件的时机，在手指接触屏幕期间可以拿到精确到像素级的滚动意图。
基础实现如下，核心是在touchmove里用当前touch坐标与起始坐标的差值，结合读取到的scrollTop做实时判断：
const state = {
startY: 0,
startScrollTop: 0,
lastY: 0,
lastTime: 0,
velocity: 0
};
document.addEventListener('touchstart', (e) => {
const touch = e.touches[0];
state.startY = touch.clientY;
state.startScrollTop = window.pageYOffset;
state.lastY = touch.clientY;
state.lastTime = Date.now();
state.velocity = 0;
}, { passive: true });
document.addEventListener('touchmove', (e) => {
const touch = e.touches[0];
const now = Date.now();
const dt = now - state.lastTime;
if (dt > 0) {
state.velocity = (state.lastY - touch.clientY) / dt; // px/ms
}
state.lastY = touch.clientY;
state.lastTime = now;
// 主动计算预计滚动位置，不依赖scroll事件
const estimated = state.startScrollTop + (state.startY - touch.clientY);
updateStickyNav(estimated);
}, { passive: true });
document.addEventListener('touchend', () => {
// 松手后根据速度估算惯性滚动终点
const momentum = state.velocity * 400; // 经验系数
const target = window.pageYOffset + momentum;
animateTo(target);
}, { passive: true });
function updateStickyNav(pos) {
const nav = document.querySelector('.nav');
nav.classList.toggle('fixed', pos > 200);
}注意这里把touch事件的passive选项设为true，表示不会调用preventDefault，这样浏览器可以放心地继续默认滚动行为，不会阻塞合成器线程，滚动流畅性不受影响。如果你在touchmove里频繁操作DOM（比如切换吸顶样式），要确保这类操作做了状态去重，只在状态真正变化时才写入class，否则每帧都改DOM同样会掉帧。
这个方案的优点是手指拖动阶段的检测精度极高，可以做到与视觉滚动几乎同步。缺点是惯性阶段依然处于"盲区"——手指离开屏幕后浏览器接管滚动，你的代码无法感知中间过程。所以实践中通常采用混合策略：拖动阶段用touch事件精确跟踪，惯性阶段用scroll事件做兜底，并用requestAnimationFrame在每帧读取最新值而不是依赖事件回调里的快照。
混合策略与scrollend事件的取舍
综合前面两种手段，生产环境推荐的完整方案是分阶段处理。手指按住屏幕时走touchmove路径，保证实时性；松手后切换到scroll监听，配合rAF循环读取滚动值；当连续多帧滚动值不再变化时，判定滚动结束，结束检测循环。这样既避免了惯性阶段的取值滞后，也不会长时间空转浪费性能。
let rafId = null;
let lastPos = -1;
let stableFrames = 0;
function trackScroll() {
const pos = window.pageYOffset;
if (pos === lastPos) {
stableFrames++;
} else {
stableFrames = 0;
lastPos = pos;
}
applyScrollLogic(pos); // 每帧用最新值做判断
if (stableFrames < 5) {
rafId = requestAnimationFrame(trackScroll);
} else {
rafId = null;
onScrollEnd(pos);
}
}
window.addEventListener('touchend', () => {
// 松手后启动rAF循环，追踪惯性滚动
if (rafId === null) {
stableFrames = 0;
rafId = requestAnimationFrame(trackScroll);
}
}, { passive: true });值得一提的是，现代浏览器已经提供了专门的scrollend事件，它在滚动真正停止后才触发，语义上正是我们想要的"滚动结束"信号。Chrome从114版本开始支持，Firefox也早已支持，但Safari的支持起步较晚，iOS上的兼容性需要通过上述rAF方案做降级。可以用特性检测决定走哪条路径：
if ('onscrollend' in window) {
window.addEventListener('scrollend', () => {
onScrollEnd(window.pageYOffset);
});
} else {
// 降级为rAF轮询方案
setupRafFallback();
}除了事件层面的优化，还有几个工程上的建议。第一，凡是需要在滚动中读取的布局信息，比如元素距离文档顶部的偏移，尽量在滚动开始前一次性计算缓存，不要在scroll回调或rAF循环里反复调用getBoundingClientRect和offsetTop，否则强制布局会让性能雪上加霜。第二，吸顶、显隐按钮这类视觉反馈，能切换class就不要直接改style，class切换会被浏览器批量处理，配合will-change: transform或transform位移代替top修改，可以把开销压到合成层。第三，测试时不要只在自己的高性能手机上看效果，用Chrome DevTools的CPU降速模拟低端设备，才能暴露出取值滞后的真实程度。
总结一下：移动端scrollTop获取异常本质上是事件派发时机与视觉滚动不同步的问题，触摸事件提供了绕开这一时序问题的入口。拖动阶段用touchmove主动计算，惯性阶段用rAF循环读最新值或依赖scrollend事件收尾，再辅以布局信息缓存和合成层优化，就能在各类移动设备上实现稳定可靠的滚动检测。