节流函数需作用于scroll事件监听器而非loadmore内部，配合触底判断、loading状态锁及hasmore标识共同控制加载频率与时机，避免重复请求。
节流函数在无限滚动中不是“自动生效”的，它需要和滚动事件、加载逻辑配合使用，核心是控制加载请求的触发频率，避免频繁触发导致重复加载或接口压力过大。
节流函数要作用在 scroll 事件监听器上
无限滚动依赖监听页面滚动，但用户快速滑动时 scroll 事件会高频触发（每秒几十次），直接在里面调用加载逻辑会导致多次重复请求。节流就是把这堆密集触发“压平”成有间隔的执行。
- 不要把节流套在 loadMore() 函数内部，而应包裹整个 onScroll 处理逻辑
- 典型写法：window.addEventListener('scroll', throttle(handleScroll, 200))，其中 handleScroll 负责判断是否触底、触发加载
- 节流时间（如 200ms）不宜过短（失去节流意义），也不宜过长（滚动到底部后延迟加载明显）
触底判断必须独立于节流逻辑
节流只控制执行频率，不改变判断条件。是否该加载，仍需每次（或节流后）检查是否接近页面底部。
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 常用判断： window.innerHeight + window.scrollY >= document.documentElement.scrollHeight - 100
- 这个计算必须放在节流后的回调里（比如 handleScroll 内），不能只靠节流来“代替”判断
- 建议加 loading 状态锁（如 isLoading = true），防止节流窗口期内多次进入加载逻辑
加载完成后要重置状态，否则可能卡住
节流不会记住你是否已加载完毕，它只按时间放行函数。如果加载失败或数据为空，没更新状态，后续滚动可能反复触发无效请求。
- loadMore() 成功后：设置 isLoading = false，并可选更新 lastPage 或 hasMore 标志
- 加载失败时也要设 isLoading = false，否则滚动再快也触发不了下一次
- 若后端返回空数组或 isLastPage: true，应标记 noMore = true，后续直接 return，跳过加载
更稳妥的做法：节流 + 防抖 + 状态控制三者结合
纯节流在快速来回滚动时仍有冗余调用；防抖适合“停顿后执行”，但无限滚动要求“滚动中尽早响应”。实际项目常混合使用：
- 用节流控制基础频率（如 150ms），保证滚动中能及时响应
- 在 handleScroll 里加简单防抖兜底：比如记录上次加载时间，距上次加载不足 500ms 则跳过
- 始终以 isLoading 和 hasMore 为第一判断依据，节流只是优化手段，不是业务逻辑主体
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
