@wheel事件如何准确判断滚动到底部？

Question

在监听 `@wheel` 事件实现滚动到底部触发加载更多内容时，开发者常面临如何**精确判断已滚动至容器底部**的问题。由于 `wheel` 事件频繁触发且 deltaY 值受设备差异影响，直接通过 `scrollTop + clientHeight >= scrollHeight` 判断易出现误判或延迟响应。特别是在快速滚动、惯性滚动或高倍数 DPI 设备下，该条件可能短暂成立或不成立，导致加载逻辑重复触发或漏触发。如何结合节流策略与容差阈值（threshold），在保证性能的同时准确识别“真正触底”，成为实现流畅用户体验的关键难点。

Answer 1

监听 @wheel 事件实现滚动到底部加载更多：从原理到高精度触底判断的完整实践

1. 基础概念：滚动触底判断的核心公式

在 Web 开发中，判断一个可滚动容器是否已滚动到底部，通常依赖以下 DOM 属性：

• scrollTop：元素内容垂直滚动的距离。
• clientHeight：元素可视区域的高度（不含滚动条）。
• scrollHeight：元素内容的实际总高度（含溢出）。

因此，触底条件为：

scrollTop + clientHeight >= scrollHeight

然而，这一公式在实际应用中存在诸多边界问题。

2. 实际挑战：为何简单判断会失效？

当使用 @wheel 事件监听滚动时，以下因素导致上述公式不可靠：

问题类型	成因分析	典型表现
高频触发	wheel 事件在快速滚动中每秒可触发数十次	加载逻辑被重复执行
惯性滚动	触摸板或移动端惯性滑动导致 scrollTop 持续变化	短暂“触底”后又回弹
DPI/缩放差异	deltaY 值受设备 DPI 和浏览器缩放影响	不同设备下滚动步长不一致
浮点精度误差	scrollTop 可能为小数（如 100.33）	等式判断失败

3. 解决思路一：引入容差阈值（Threshold）

为避免因浮点误差或轻微滚动未完全触底而漏判，应设置一个向下容错范围。例如，当距离底部小于 5px 时即视为“接近底部”：

const threshold = 5;
const isNearBottom = scrollTop + clientHeight + threshold >= scrollHeight;

该策略提升了判断的鲁棒性，尤其适用于高 DPI 设备或非整数滚动增量场景。

4. 解决思路二：结合节流（Throttle）控制事件频率

直接响应每一次 wheel 事件会导致性能浪费和逻辑混乱。采用节流函数限制处理频率至 100~150ms 一次：

function throttle(fn, delay) {
    let timer = null;
    return function (...args) {
        if (timer) return;
        timer = setTimeout(() => {
            fn.apply(this, args);
            timer = null;
        }, delay);
    };
}

将触底检测逻辑包裹在节流函数中，有效降低 CPU 占用并防止重复加载。

5. 高级策略：状态机控制加载状态

即使有了节流与阈值，仍可能因用户反复滚动导致多次请求。引入状态标记可进一步优化：

let isLoading = false;
let hasMore = true;

function handleScroll() {
    if (isLoading || !hasMore) return;

    if (isNearBottom(container)) {
        isLoading = true;
        loadMoreData().finally(() => {
            isLoading = false;
        });
    }
}

通过状态隔离，确保每次加载完成前不会发起新请求。

6. 综合方案设计流程图

graph TD
            A[监听 @wheel 事件] --> B{是否节流窗口内?}
            B -- 是 --> C[忽略本次事件]
            B -- 否 --> D[计算当前滚动位置]
            D --> E{scrollTop + clientHeight + threshold >= scrollHeight?}
            E -- 否 --> F[更新节流窗口]
            E -- 是 --> G{isLoading 或 !hasMore?}
            G -- 是 --> F
            G -- 否 --> H[设置 isLoading = true]
            H --> I[发起 loadMore 请求]
            I --> J[更新数据 & DOM]
            J --> K[重置 isLoading]
            K --> F

7. 边界情况处理建议

• 首次渲染时若内容不足一屏，应自动加载下一页（避免无法触发 wheel）。
• 动态内容插入后需重新计算 scrollHeight，必要时手动触发一次触底检测。
• 移动端 Safari 存在弹性滚动（rubber banding），可能导致 scrollTop 超出理论范围，建议增加 Math.max(0, ...) 保护。
• 考虑使用 Intersection Observer 替代部分 wheel 逻辑，用于监听“最后一条数据”是否可见。

这些细节决定了用户体验的平滑程度。

8. 性能监控与调试技巧

在生产环境中，可通过如下方式验证触底逻辑稳定性：

console.debug(`Scroll: ${scrollTop}, View: ${clientHeight}, Total: ${scrollHeight}, Near Bottom: ${isNearBottom}`);

同时建议记录：

1. 节流间隔的实际触发次数
2. loadMore 调用频率
3. 触底判断的成功率（对比预期与实际加载时机）
4. 不同设备/DPI下的 deltaY 分布
5. 内存占用变化趋势
6. 帧率（FPS）波动情况
7. 是否出现跳屏或闪烁
8. 网络请求并发数
9. 错误重试机制有效性
10. 用户平均滚动速度统计

9. 可扩展架构设计

对于大型项目，可将该逻辑封装为可复用的 Composition API 或 React Hook：

function useInfiniteScroll(containerRef, loadMore, options = {}) {
    const { threshold = 10, throttleDelay = 150 } = options;
    // ... 实现细节
}

支持传入自定义判断函数、外部状态控制、取消机制等高级特性。

10. 未来方向：结合现代浏览器 API 进一步优化

随着浏览器能力演进，可探索以下替代或补充方案：

• ScrollTimeline + Animation：实验性 API，可用于精确追踪滚动进度。
• requestIdleCallback：在空闲时段执行非关键检测逻辑。
• ResizeObserver：监听容器尺寸变化，动态调整判断基准。
• Pointer Events：区分鼠标滚轮、触摸板、触屏手势，差异化处理 deltaY。

这些技术组合可构建更智能、自适应的无限滚动系统。