IntersectionObserver构造函数的options参数不是必须的，但不传会导致默认root为视口、threshold为[0]，无法满足懒加载等需提前触发的场景，易引发白屏或回调不执行等问题。
IntersectionObserver 构造函数必须传 options 吗？
不是必须，但不传会踩坑。默认 root 是浏览器视口、threshold 是 [0]，看似合理，但实际中多数图片懒加载需要「提前触发」——比如在元素离视口顶部还有 200px 时就开始加载，避免滚动过快导致白屏。这时候必须显式传 { rootMargin: '200px 0px 0px 0px', threshold: 0 }。
常见错误现象：IntersectionObserver 回调一直不执行，或只在元素完全进入视口后才触发，导致图片闪现或加载延迟。
-
rootMargin支持类似 CSS margin 的写法（如'100px'、'50px 0 -100px'），负值也合法，用于「缩进」检测区域 -
threshold是数组，设为[0, 0.25, 0.5, 0.75, 1]可获取更细粒度的交叉比例，但懒加载一般用0就够了 - 若页面有滚动容器（如
overflow-y: scroll的 div），需把该容器作为root，否则监听无效
如何避免重复触发和内存泄漏？
每个 img 都 new 一个 IntersectionObserver 是典型反模式。正确做法是复用单个实例，统一管理所有懒加载节点；同时必须在元素进入视口并加载完成后调用 observer.unobserve(target)，否则回调持续触发，且 DOM 节点无法被 GC。
使用场景：页面含大量卡片列表，每张卡片含一张懒加载图；若未及时 unobserve，滚动过程中会不断触发回调，CPU 占用明显升高。
- 不要在回调里直接写
img.src = img.dataset.src后就结束——得先检查img.dataset.src是否已赋值，防止重复加载 - 如果图片加载失败，建议 fallback 到占位图，并同样调用
unobserve，否则会卡在 pending 状态反复重试 - 页面销毁前（如 SPA 路由切换），应调用
observer.disconnect()，否则 observer 持有 DOM 引用，造成内存泄漏
图片加载完成后再替换 src，为什么还会闪动？
因为 img.src 赋值瞬间开始网络请求，浏览器渲染线程还没拿到解码后的图像，会短暂显示空白或浏览器默认缺省图。这不是 IntersectionObserver 的问题，而是加载时机与渲染流程不同步所致。
解决方案是预创建 Image 实例，等 onload 触发后再替换真实 img 的 src，或者用 loading="lazy" 原生属性兜底（但兼容性有限）。
- 推荐做法：在
intersectionCallback中创建const preImg = new Image()，绑定preImg.onload = () => { target.src = preImg.src; observer.unobserve(target); } - 别忘了
preImg.onerror处理，否则加载失败时整个流程就卡死了 - 如果项目已用 Webpack/Vite，可配合
import('./placeholder.svg')动态引入占位图，避免 base64 冗余
IE 浏览器下完全不工作怎么办？
IntersectionObserver 在 IE 中彻底不可用，没有 polyfill 能完美模拟其性能表现。强行用 getBoundingClientRect() + scroll 事件轮询，会严重拖慢滚动帧率，尤其在长列表中。
务实策略是降级：对 IE 用户直接关闭懒加载，让所有 img 的 src 在 HTML 中就存在；或改用 loading="eager" 强制立即加载。
- 可用
if ('IntersectionObserver' in window)做特性检测，而非 UA 判断 - 服务端渲染（SSR）场景下，IE 用户首次打开页面时，应确保关键首屏图片已直出
src，避免白屏 - 注意：某些 polyfill（如 w3c/IntersectionObserver）仅提供 API 兼容，不解决性能问题，生产环境慎用
实际中最容易被忽略的是 rootMargin 的单位必须带 px/em/% 等，漏写单位会导致整个配置静默失效；还有就是忘记在 onload 之后调用 unobserve，这个问题在线上埋点里常表现为「已加载图片仍持续上报进入视口事件」。
