如何基于 IntersectionObserver 设计一套具备感知式预加载能力的组件延迟渲染器
为什么直接用 threshold 做预加载不可靠
很多开发者会想当然地认为，把 threshold 设置成 [0, 0.25] 就能实现“提前触发”。但现实情况往往更骨感：当元素刚刚露出四分之一时，网络请求可能才发出去，图片还没下载完，用户就已经把它滚出视线了。更麻烦的是，threshold 是基于比例的阈值，而非固定的像素偏移——这导致它对不同高度的元素响应极不一致。一个只有10像素高的按钮，在0.25的阈值下几乎无法被触发；而一张800像素高的横幅广告，却可能过早地被激活，白白浪费了资源。
rootMargin 才是预加载的真正开关
想要实现可控、可预测的预加载，关键在于用好 rootMargin。这个参数允许你将“视口边界”向外扩展，让观察器在元素实际进入屏幕之前，就提前感知到它的存在。
- 写法必须规范：必须是
'200px 0px 0px 0px'这样的格式（顺序为上、右、下、左），只写200或'200px'是无效的，会被浏览器直接忽略。 - 负值也合法：设置如
'-100px 0px 0px 0px'，意味着只有当元素已经进入视口100像素后，才开始观察，这能有效防止误触发。 - 移动端注意点：
vh单位在部分iOS Safari版本中支持不佳，优先使用px更为稳妥。 - 判断逻辑：配合
isIntersecting === true进行判断，而不是仅仅依赖intersectionRatio。这样可以避免因用户滚动过快，导致比例值来不及更新而错过触发时机。
如何避免重复加载与内存泄漏
延迟渲染器一旦需要管理多个目标元素，如果清理不及时，很容易积累大量未卸载的 IntersectionObserver 实例，这在React或Vue的列表重渲染场景下尤为常见。
- 观察一次即可：对同一个目标元素，只需调用一次
observer.observe(target)。重复调用虽然不会报错，但会覆盖之前的状态。 - 及时取消观察：加载完成后，应立即调用
observer.unobserve(target)，不要等待全局的disconnect()——后者会停掉整个观察器，影响其他正在被观察的目标。 - 组件卸载是底线：在组件卸载的生命周期（如React的
useEffect清理函数、Vue的beforeUnmount）中，必须调用observer.disconnect()。否则，观察器会持续持有DOM引用，导致内存无法被垃圾回收。 - 保持异步优势：避免在回调函数里直接操作
target的innerHTML或进行大量的DOM插入。这些同步操作会触发重排（layout），从而抵消掉IntersectionObserver本身的异步性能优势。
复杂滚动容器下的 root 配置陷阱
当你的目标元素并非相对于文档视口，而是嵌套在一个 overflow: auto 的容器内滚动时，问题就来了。此时设置 root: null 会完全失效，因为它只监听文档层级的滚动，对容器内部的滚动毫无反应。
- 显式指定容器：必须将容器节点作为
root参数传入，例如：root: document.querySelector('.scroll-container')。 - 确保关系与时机：该容器必须是目标元素的祖先节点，并且已经渲染完成。如果容器是动态插入的，务必确保
observer在容器挂载之后再创建。 - 样式可能带来的坑：如果容器设置了
transform或will-change属性，在某些旧版本的Chrome中可能会错误计算交叉区域（intersectionRect）。一个可行的修复方案是给容器加上contain: layout style paint样式。 - 分清参数类型：不要混淆
root和rootMargin的单位逻辑。前者接受一个DOM节点，后者接受一个字符串形式的样式值，两者之间没有隐式转换。
说实话，真正的难点往往不在于如何注册一个observer，而在于决定「什么时候取消观察」以及「什么时候需要重新注册」。比如，当用户快速来回滚动时，已经加载过的组件状态是否需要保留？这些边界情况的处理逻辑，其代码量往往是初始化部分的三倍以上，却极少在官方文档中被详细提及。这才是考验功力的地方。
