最推荐使用 IntersectionObserver 监听元素可见性变化——它是浏览器原生、高性能、专为此设计的 API，不依赖 scroll 事件，避免重排重绘；手动用 scroll + getBoundingClientRect 存在性能压力、兼容性复杂、无法准确判断真实可见性等问题。
JavaScript 中监听元素可见性变化，最推荐的方式是使用 IntersectionObserver —— 它是浏览器原生、高性能、专为此类场景设计的 API，不依赖滚动事件，也不触发重排重绘。
为什么不用 scroll + getBoundingClientRect 手动判断？
手动监听 scroll 事件并调用 getBoundingClientRect() 虽然可行，但存在明显缺点：
- 频繁触发 scroll 会导致主线程压力大，尤其在快速滚动时
- 需要自行处理节流、兼容性（如 iframe、缩放、position: fixed 等边界情况）
- 无法准确反映“是否真正可见”——比如被
overflow: hidden父容器裁剪、或被其他元素遮挡时，getBoundingClientRect仍可能返回非空区域
IntersectionObserver 的核心用法
只需三步即可启用：
-
创建观察器：传入回调函数，接收
entries（交叉状态数组）和observer（实例本身） -
配置触发条件（可选）：
threshold控制可见比例阈值（如[0, 0.25, 0.5, 1]），rootMargin可提前触发（如'200px'实现懒加载预加载） -
开始监听：对已挂载的 DOM 元素调用
observe(element)
示例：
立即学习“Java免费学习笔记（深入）”；
const io = new IntersectionObserver((entries) => {entries.forEach(entry => {
if (entry.isIntersecting) {
console.log('元素进入视口', entry.target);
}
});
}, { threshold: 0.1 });
io.observe(document.querySelector('.card'));
注意布局样式导致的失效
即使代码正确，也可能收不到回调。常见原因包括：
- 目标元素或其任意父级设置了
overflow: hidden且裁剪了该元素 - 目标元素为
display: none或visibility: hidden（后者仍可被观测到，但isIntersecting为false） - 目标不在文档流中（如未插入 DOM、或被
transform: scale(0)隐藏但未脱离渲染树） - 指定了
root但该容器没有显式高度，或未设置overflow: auto/scroll
动态内容场景下的注意事项
对于 Vue/React 等框架中异步渲染的列表项：
- 不能只在初始化时 observe 一次，新节点插入后需再次调用
observe() - 组件卸载前建议调用
unobserve(element)或disconnect()，避免内存泄漏 - 若需监听整个容器内所有子项，可观察容器，再通过
entries[i].target区分具体元素
