scroll事件默认高频触发（每帧可能执行），易致卡顿或重复请求，需通过节流（如100ms限频）、触底计算（innerHeight+scrollY≥scrollHeight−50）及加载锁（loading/hasMore状态控制）优化。
监听 scroll 事件时，为什么 window.onscroll 或 addEventListener('scroll') 总是触发太频繁？
直接绑在 window 上的 scroll 监听器会在滚动过程中高频触发（每帧都可能执行），极易导致卡顿或重复请求。这不是浏览器 bug，而是默认行为。
关键不是“禁用”，而是“节流”和“时机判断”：
- 用
requestIdleCallback或简单节流函数（如 100ms 内最多执行一次）包裹加载逻辑 - 真正该检查是否触底的，是每次触发时计算
window.innerHeight + window.scrollY >= document.documentElement.scrollHeight - 50（留 50px 容错） - 务必在发起新请求前加锁：
if (loading || hasMore === false) return;，避免用户快速滚动时发多次请求
后端返回数据后，innerHTML += ... 拼接列表为什么越来越慢？
字符串拼接再整段赋值会强制浏览器反复解析 HTML、重建 DOM 树，尤其列表长了以后，性能断崖式下跌。
更稳的做法是批量操作：
立即学习“前端免费学习笔记（深入）”；
- 用
document.createDocumentFragment()缓存所有新节点，最后一次性appendChild到容器 - 或用
insertAdjacentHTML('beforeend', htmlString)，它比innerHTML +=少一次完整重排，且不破坏已有绑定的事件监听器（前提是没用内联onclick） - 如果列表项有交互（如点赞），优先用事件委托绑定到父容器，别给每个新元素单独绑
滚动到底部时请求失败，用户再滚一次就重复加载同一页？
这是状态管理缺失的典型表现——没有区分“空闲”“加载中”“加载完成”“加载失败”四种状态。
必须维护一个明确的状态变量，并在合适时机更新：
- 请求前设
loading = true，同时可临时禁用滚动监听（或忽略后续触发） - 成功后：更新
page += 1，设loading = false；若返回空数组，设hasMore = false - 失败后：设
loading = false，并建议加个“重试”按钮（或允许用户再滚一次，但需加防抖） - 不要靠“有没有新数据”来判断是否结束，而应以接口明确返回的
has_more: false或total_count 为准
移动端 Safari 和微信 WebView 中，scroll 事件为什么不触发或延迟？
iOS WebKit 对非用户手势触发的滚动（比如 JS 滚动、页面加载后自动滚动）会禁用 scroll 事件，且某些 WebView 会把 scroll 事件合并到 touchend 后统一派发。
绕过方式很实际：
- 改用
IntersectionObserver监听底部占位元素（如一个<div id="loader-trigger"></div>）是否进入视口，兼容性好、性能优、不依赖 scroll - 如果必须用 scroll，确保容器是
body或设置了overflow-y: auto的局部容器（注意 iOS 需要-webkit-overflow-scrolling: touch） - 微信 WebView 里，有时需在
touchmove中手动触发一次scroll检查，但仅作兜底，别作为主逻辑
实际复杂点不在“怎么滚”，而在“怎么知道该不该滚”和“滚完怎么稳住状态”。边界条件（网络失败、用户狂滚、后端翻页错乱）比主流程更消耗调试时间。
