无限滚动的核心判断逻辑是检测用户是否接近页面底部，而非单纯监听滚动事件；主流做法是通过比较scrollHeight、innerHeight和scrollY，并设置阈值触发加载，且必须使用document.documentElement以避免兼容性问题。
无限滚动的核心判断逻辑是什么
关键不是“滚动”，而是判断用户是否接近页面底部。主流做法是监听 scroll 事件，每次触发时比较 document.documentElement.scrollHeight、window.innerHeight 和 window.scrollY，当 scrollY + innerHeight >= scrollHeight - threshold（比如 200px）时触发加载。
注意：必须用 document.documentElement 而非 document.body，否则在某些浏览器（如 Safari）下会因 body.scrollTop 始终为 0 导致判断失效。
为什么直接监听 scroll 会出问题
scroll 事件在滚动过程中高频触发（每秒几十次），若每次触发都执行异步请求或 DOM 插入，极易造成卡顿、重复请求、甚至内存泄漏。
- 重复请求：用户快速滚动到底部，节流没做，
loadMore()被调用多次，后端收到多个相同分页请求 - DOM 渲染阻塞：未控制插入节奏，大量节点批量追加导致重排重绘压力陡增
- 事件监听残留：组件卸载后未移除监听器，
this指向丢失或引发内存泄漏
滚动节流的两种可靠实现方式
推荐使用 setTimeout + 标志位，比 lodash.throttle 更轻量、可控性更强，且避免第三方依赖带来的打包体积和兼容性风险。
let isScrolling = false;
const handleScroll = () => {
if (isScrolling) return;
isScrolling = true;
setTimeout(() => {
const { scrollHeight, clientHeight } = document.documentElement;
const scrollTop = window.scrollY || window.pageYOffset;
const threshold = 200;
if (scrollTop + clientHeight >= scrollHeight - threshold) {
loadMore();
}
isScrolling = false;}, 150);
};
window.addEventListener('scroll', handleScroll);
另一种更精确的方式是用 IntersectionObse
rver 监听底部占位元素（推荐用于现代项目）：
const sentinel = document.createElement('div');
sentinel.className = 'infinite-sentinel';
document.body.appendChild(sentinel);
const observer = new IntersectionObserver(
([entry]) => {
if (entry.isIntersecting && !loading) {
loadMore();
}
},
{ threshold: 0.1 }
);
observer.observe(sentinel);
优势：不依赖 scroll 事件，无节流必要；自动处理滚动方向、iframe、移动端等边界情况；但需确保 sentinel 始终在 DOM 中且位置正确（通常放在列表末尾）。
容易被忽略的边界细节
无限滚动不是“加个监听就完事”，真实场景中这些点常导致线上故障：
rver- 加载状态未锁定：
loading标志必须在请求发起前置为true，响应后才置为false，否则快速滚动可能连续触发多次 - 最后一页未标记：
hasMore === false后应移除监听器或忽略后续触发，否则仍会尝试请求不存在的页码 - 动态内容高度变化：比如图片懒加载完成、广告位注入，会导致
scrollHeight突然增大，原底部判断失效——此时需要重新计算或用IntersectionObserver自动响应 - 移动端 touchmove 兼容：iOS Safari 对
scroll事件触发时机有延迟，建议配合touchend补充一次检查
最麻烦的其实是数据一致性：用户滚动过程中刷新页面，如何恢复到上次位置并避免重复加载？这已经超出滚动本身，得结合路由参数或本地存储做状态同步。
