实现触底加载（无限滚动）的关键，在于精准捕捉“滚动到底部”的瞬间。许多开发者习惯性地使用 window.onscroll 配合大量高度计算，但这不仅容易高频触发、导致页面卡顿，判断逻辑也常出现错误。问题的本质不在于滚动事件本身，而在于如何优雅地监听容器可视区域与内容末尾之间的交叉状态变化。
这正是 IntersectionObserver API 的用武之地。该 API 设计初衷就是观察元素与视口的交叉情况，用它来实现触底加载，语义上更加贴切，性能也更优——因为它不会阻塞主线程。具体做法是：观察列表中的最后一个元素（例如一个带有特定类名的 ），只要该元素有一小部分进入视口，就触发加载动作。这能有效避免用户看到“差一点到底”的尴尬空白区域。
当然，仅触发加载还不够，流程管理同样重要。加载过程中，需要先用 unobserve 临时取消对末尾元素的监听，防止重复请求；等新数据插入后，再重新定位到新的最后一个元素并执行 observe。这套“观察—取消—重新观察”的动态管理机制，是保证无限滚动流程顺畅的核心。
必须显式处理加载的“终点”
无限滚动设计中最容易被忽视的一环，是如何明确地告知程序：“没有更多数据了”。如果后端返回空数组、has_more: false 或者直接返回 404 状态码，而前端没有相应的终止逻辑，用户就会陷入不断下拉、页面却毫无反应的困惑中，甚至可能触发错误。
一个健壮的解决方案需要三层判断：
- 网络层失败：当
fetch请求本身抛出异常时，可进行有限次重试（例如最多1次），之后应向用户清晰提示“加载失败”，并提供“点击重试”按钮，而不是让流程静默中断。 - 业务层无数据：请求成功，但返回的数据数组长度为 0。此时应将状态标记为
hasMore = false，并移除 IntersectionObserver 的观察，彻底停止监听。 - 分页标识终结：如果接口通过
next_cursor或page等字段标识下一页，当这些字段值为null或空字符串时，同样意味着数据已加载完毕，应执行与上一步相同的终止操作。
注意DOM操作对体验与性能的影响
拿到新数据后，直接循环调用 append() 将新节点插入列表末尾，是最直观的做法，但也可能带来问题。一是可能引起滚动位置突变，在 iOS Safari 等浏览器中尤其明显；二是多次连续的 DOM 插入会触发浏览器频繁的重排（Reflow），影响前端性能。
对此，可以采取几个优化策略：
- 使用
DocumentFragment作为“离线”的 DOM 片段，先将所有新节点在其中构建好，再一次性插入到真实 DOM 中，能显著减少重排次数。 - 在插入新内容前，记录下容器当前的滚动高度（
scrollTop），插入完成后立即将滚动高度恢复回去，可以避免页面内容突然“跳动”。 - 对于超长列表（例如超过 500 条），就需要考虑虚拟列表（Virtual List）技术。不过，在纯 HTML/JS 场景下，如果暂时不想引入复杂方案，一个务实的建议是：为列表添加“回到顶部”按钮，并对渲染进行节流控制。
移动端的特殊挑战与应对
在移动端浏览器或 WebView 中，快速滑动产生的惯性滚动可能会让 IntersectionObserver 的回调被多次触发，造成“假触底”。此外，未正确处理的 touchmove 事件也可能干扰滚动判定。
要解决这些问题，可以注意以下几点：
- 为滚动容器设置
touch-action: pan-y，明确允许垂直滚动，同时禁用可能造成干扰的横向拖拽行为。 - 确保滚动容器本身具有明确的高度（例如
max-height: 70vh）和overflow-y: auto样式。避免依赖body元素的自然滚动，因为有时会导致 Observer 无法正确工作。 - 在 Observer 的回调函数中加入简单的防抖逻辑，例如用
setTimeout延迟 100 毫秒再执行加载函数，可以有效过滤掉滚动惯性带来的瞬时多次触发。
说到底，在许多实际场景中，一个明确的“加载更多”按钮可能比全自动的无限滚动更可控、体验也更清晰。而当你确实需要无限滚动时，除了上述实现细节，务必在项目上线前重点检查两件事：一是 IntersectionObserver 的浏览器兼容性（它不支持 IE），二是空数据与错误状态的兜底处理是否完备。这两处，恰恰是最容易遗漏的关键。
