仅用getBoundingClientRect()判断元素是否可见会误判，因它不检测遮挡、裁剪、透明度等；需结合IntersectionObserver与多点document.elementFromPoint()校验。
单纯用 getBoundingClientRect() 判断元素是否在视口内，大概率会误判——它只管“几何重叠”，不管“是否被遮挡”“是否被父容器裁剪”“是否 opacity: 0 或 visibility: hidden”。真正在意“用户能不能看到”，必须叠加多层校验。
getBoundingClientRect() 只能判断几何可见性，不能反映真实可视状态
这个 API 返回的是元素盒模型相对于视口左上角的坐标（top、left、bottom、right），但以下情况它完全无法识别：
-
display: none或visibility: hidden的元素仍可能返回有效矩形（尤其在动画过渡中） - 父级设置了
overflow: hidden，子元素部分伸出但被裁剪，getBoundingClientRect()仍认为“在视口内” - 高
z-index的弹层、广告位、模态框盖住了目标元素，它毫无感知 -
opacity: 0或transform: scale(0)下元素仍在文档流中，矩形也正常
所以仅靠 rect.top 0 这类判断，适合做懒加载占位图触发，但不适用于交互逻辑（比如“只允许点击真正可见的菜单项”）。
IntersectionObserver 是现代首选，但默认不检测遮挡
IntersectionObserver 比手动监听 scroll 更轻量、更准确，尤其对滚动容器（如 div[style="overflow-y: auto"]）天然支持。但它只解决“是否相交”，不解决“是否被盖住”：
立即学习“前端免费学习笔记（深入）”；
- 它的
entry.isIntersecting为true，只说明元素与根（默认视口）有面积交集 -
entry.intersectionRatio告诉你可见比例，但不告诉你这 30% 是不是全被另一个div盖住了 - 若需严格语义（例如：下拉菜单最后一项必须“可点且可见”），必须在回调里补一手
document.elementFromPoint()
示例关键片段：
const observer = new IntersectionObserver((entries) => {
entries.forEach(entry => {
if (!entry.isIntersecting) return;
const el = entry.target;
const rect = el.getBoundingClientRect();
const x = rect.left + rect.width / 2;
const y = rect.top + rect.height / 2;
const topEl = document.elementFromPoint(x, y);
if (topEl && (topEl === el || el.contains(topEl))) {
console.log('真正可见且可交互');
}
});
}, { threshold: 0.1 });
document.elementFromPoint() 是遮挡检测的核心，但有使用限制
这个方法返回指定视口坐标点上层最接近的元素，是验证“未被遮挡”的直接依据。但它有几个硬约束，容易踩坑：
- 坐标必须是视口坐标（不是文档坐标），所以必须用
getBoundingClientRect()算出的left/top，不能用offsetTop或scrollTop手动加减 - 如果目标元素本身不可见（
display: none），elementFromPoint()可能返回null或其兄弟元素，需前置检查渲染状态 - 采样单点（如中心）不够鲁棒，建议至少测 5 点（四角 + 中心），任一点命中即算通过；否则窄高元素（如垂直分割线）易漏判
- 该方法受
pointer-events: none影响——若遮挡层设了这个，它会“穿透”，误判为未遮挡
因此完整流程必须是：isElementRendered(el) → isInViewport(el) → 多点 elementFromPoint() 校验。
复杂场景下，祖先节点裁剪和 transform 会影响所有判断
当目标元素嵌套在 transform: translateZ(0)、will-change: transform 或带 clip-path 的祖先中时，getBoundingClientRect() 返回的矩形可能已失真：
-
transform会改变元素视觉位置，但getBoundingClientRect()返回的是变换后的位置（这是对的），而elementFromPoint()采样点必须基于这个变换后坐标——这点常被忽略 -
clip-path或mask裁剪后的“不可见区域”，elementFromPoint()仍可能命中元素本身（因为 DOM 结构未变），需额外结合getComputedStyle(el).clipPath分析 - 滚动容器内元素，
IntersectionObserver默认能处理，但若容器用了contain: paint，某些浏览器可能提前裁剪，导致isIntersecting延迟触发
这类边界情况没有银弹，必须在真实 DOM 结构和 CSS 上下文中实测，不能只依赖通用函数。
