最稳定做法是用IntersectionObserver观察底部占位元素：在列表末尾插入无高度的，配置rootMargin提前触发，每次加载后重新observe，并优先用document.documentElement.scrollTop、配合loading状态和后端has_more字段防重复请求。
怎么判断滑动到底部触发加载
直接用 window.onscroll 监听 + 手动算 scrollTop + clientHeight >= scrollHeight 是最常见写法，但容易在缩放、iOS Safari 弹性滚动、iframe 嵌套等场景下失准。真正稳定的做法是用 IntersectionObserver 观察底部占位元素。
关键点：
- 在列表末尾插入一个
<div id="loader-trigger"></div>，不设高度，仅作观察目标 - 创建 observer 时必须设
rootMargin: '0px 0px 200px 0px'，提前 200px 触发，避免用户“拉到边才动” - 每次加载完新数据后，要重新调用
observer.observe(triggerEl)，因为 DOM 替换可能导致 target 脱离观察 - 不要依赖
document.body.scrollTop判断——iOS 下它常为 0，优先用document.documentElement.scrollTop
加载中状态怎么防重复请求
滑动快一点，isIntersecting 可能连续触发两次，导致发两遍相同页码的请求。不能只靠节流，得结合业务状态控制。
实操建议：
立即学习“前端免费学习笔记（深入）”；
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 维护一个
loading布尔值，进入加载逻辑前先判断if (loading || hasMore === false) return -
hasMore必须由后端明确返回（如has_more: true或next_cursor字段），别用响应数组长度是否为 0 来判断——第一页可能有 total，后续页没有，结构不一致会误判结束 - fetch 成功后，
currentPage++；失败或空响应后，必须重置loading = false，否则后续滚动永远卡住 - 简单防抖：用
setTimeout+clearTimeout包一层，确保同一触发周期只执行一次 fetch
DOM 插入怎么避免 XSS 和崩溃
后端返回 HTML 片段或 JSON 数据后，直接 innerHTML += 拼接是最危险操作——既可能执行恶意脚本，又会在字段缺失时报 Cannot read property 'map' of undefined。
安全做法：
- 永远先校验数据结构：
Array.isArray(data.items) && data.items.length > 0再遍历 - 不用
+=，改用insertAdjacentHTML('beforeend', htmlStr)或documentFragment批量插入 - 如果后端返回的是 HTML 字符串，且来源不可信，必须过
DOMPurify.sanitize()；若只是展示文本，优先用textContent - 避免把加载提示
<div id="loading"></div>放在列表内部——它会被反复插入/移除，影响 observer 状态；应固定在列表外层容器底部
为什么 touchmove 监听不适合做底部加载
移动端底部加载不是手势操作，而是滚动位置判断。用 touchmove 去监听“用户是不是快滑到底了”，本质上是错的——它响应的是手指移动，不是内容可视区域变化。而且 iOS Safari 在 overscroll 时根本不会触发 scroll 事件，但会触发 touchmove，反而更容易误判。
典型坑：
- 在
touchmove里反复计算scrollTop，但此时页面可能还没完成滚动布局，值不准 - 没做 passive: false 声明，Chrome 会静默忽略
preventDefault()，导致后续逻辑失效 - 绑定在
document上，结果轮播图、弹窗等子组件也响应了事件，干扰主列表逻辑 - 一旦用了
touchmove，就绕不开touchstart记起点、touchend算速度、惯性补位……复杂度陡增，却没解决本质问题
真正该省力的地方，是放弃手动滚动计算，信任 IntersectionObserver 的视口检测能力——它不关心你怎么滑，只关心“那个 div 进没进眼睛里”。
