IntersectionObserver 默认以视口为根，若目标在局部滚动容器内需显式设 root 为该容器，且容器须有高度、overflow 并已挂载；rootMargin 用负值提前触发加载；observe 必须在元素插入 DOM 后调用；transform 或 contain 会干扰 root 判定。
root 不设成滚动容器会导致监听失效
IntersectionObserver 默认以视口为根容器，如果目标元素在某个 div 内滚动（比如带 overflow-y: auto 的列表容器），但没显式设置 root，那它永远只检测元素是否进入浏览器视口，而不是进入那个局部容器——结果就是：滚动子容器时，callback 根本不触发。
必须把目标滚动容器作为 root 传入，且该容器需满足两个条件：
- 有明确的高度和
overflow（如overflow-y: scroll或auto） - 在 DOM 中已挂载、可被 JS 访问到（不能是后续动态插入却未重连 observer 的情况）
常见错误写法：new IntersectionObserver(callback) —— 缺少 root；正确写法示例：
const container = document.querySelector('#infinite-list');<br>const observer = new IntersectionObserver(callback, { root: container });
rootMargin 要配合容器内边距和加载占位符调整
无限加载通常在“底部即将可见”时触发，不能等元素真进视口才加载，否则用户会看到空白或跳动。这时候靠 rootMargin 提前触发很关键——但它不是像素值直接填进去就行。
实际要算的是：从容器底部向上多少距离开始触发加载。例如容器有 padding-bottom: 20px，末尾还放了一个 loading 元素高 40px，那合理值可能是 '0px 0px -60px 0px'（负 bottom margin 表示提前触发）。
- 正数 margin 是向外扩，负数才是向内缩（即更早触发）
- 如果容器用了
border-box+padding，rootMargin的计算起点是 padding 边界，不是 content 边界 - 移动端 Safari 对大负值 margin 支持不稳定，建议控制在
-100px以内
observer.observe() 必须在目标元素真实存在后调用
无限加载中，新条目是异步插入的（比如 fetch 后 append()），如果在插入前就对所有 .item 调用 observe()，那新节点根本不会被监听——因为它们还没进 DOM。
推荐做法是：每次插入新节点后，单独对最后一个（或最后几个）节点调用 observer.observe()。不要试图复用旧节点的观察状态，也不要用 document.querySelectorAll 每次全量重绑。
- 避免内存泄漏：插入前先检查是否已被观察过（可用
observer.takeRecords()或维护一个Set记录已观察节点） - 如果用 React/Vue，确保在
ref或mounted钩子之后再 observe，而非模板渲染前 - 不要在
callback里重复调用observe()同一个元素，可能造成多次加载
滚动容器 transform 或 contain 会影响 root 判定
某些 UI 库（如 antd、element-plus）或自定义布局会给滚动容器加 transform: translateY(0) 或 contain: layout paint，这会创建新的层叠上下文和格式化上下文，导致 IntersectionObserver 无法正确识别该容器为 root——表现是 callback 完全不执行，或触发时机严重偏移。
排查方法：在 DevTools 中选中容器，看 Computed 面板里是否有 transform、contain、will-change 等属性生效。若有，临时去掉验证是否恢复。
- 最稳妥解法：移除不必要的
transform和contain，尤其不要给滚动容器加contain: strict - 若必须保留，可改用
position: relative替代transform做定位 - Chrome 120+ 对
contain: layout下的 root 支持有所修复，但 Safari 仍不可靠
真正难调的往往不是逻辑，而是 root 元素被 CSS 隐形劫持了——别急着改 JS，先打开 DevTools 看一眼 computed style。
