节流必须配合位置判断和加载锁，100ms为稳妥起点，需开启leading和trailing，节流内仅做轻量位置校验，加载动作由独立逻辑触发，并推荐用IntersectionObserver替代。
无限滚动加载中，节流不是“要不要用”的问题，而是“怎么用才不坏事”的问题——它不能替代位置判断和加载锁，只负责把高频滚动事件压到可接受的节奏里。关键不在间隔设多大，而在让每次节流执行都真正有效。
节流间隔要兼顾响应性与稳定性
100ms 是较稳妥的起点：既避免滚动过程中频繁触发（比如每秒 60 帧下滚动事件可能触发 30+ 次），又不会让用户感觉加载有明显延迟。移动端手指滑动较慢时可放宽到 150–200ms；桌面端鼠标滚轮快、惯性大，仍建议守住 100ms 上限。切忌设成 500ms 或更高——用户快速滚到底部时，可能只触发一次，且已错过最佳加载时机。
必须开启 leading 和 trailing 选项
滚动刚启动时（比如页面加载完用户立刻向下拖），要立刻检查是否已接近底部；滚动结束前最后一次靠近临界点，也要确保执行一次判断。否则容易出现“明明到底了却不加载”或“第一次滚动就漏判”的情况。
- leading: true → 首次调用立即执行，适配初始位置检测
- trailing: true → 节流周期结束后补一次执行，兜住临界点
节流函数里只做轻量判断，不做加载动作
节流回调中不应直接调用 loadMore() 或发请求，而应只运行位置校验逻辑：
立即学习“Java免费学习笔记（深入）”；
- 读取
scrollTop、scrollHeight、clientHeight（注意用document.documentElement，避开 Safari 兼容问题） - 计算
scrollTop + clientHeight >= scrollHeight - 100（留 100px 提前量，避免用户看到空白再加载） - 仅当条件满足且
!loading时，才调用实际加载函数
节流必须配合加载锁和真实位置重检
节流控频 ≠ 并发控制。即使加了节流，若用户反复快速触底，仍可能因多次节流周期内都满足条件而并发请求。因此：
- 加载开始前设
isLoading = true，完成或失败后重置 - 每次节流执行时，都重新计算滚动位置——不能依赖“上次节流时的结果”
- 推荐用
IntersectionObserver替代 scroll 监听，彻底规避节流必要性（现代项目首选）
