elementfrompoint 返回 null 或意外元素主因是坐标未对齐视口：需用 pagex−scrollx/pagey−scrolly，避开滚动、缩放、iframe 跨域及 event.clientx/clienty 直接传参；热区重叠时应向上遍历 parentnode 或用 closest() 过滤目标容器；高频调用需按坐标变化阈值（如 Δx>2px）触发而非节流/防抖。
elementFromPoint 返回 null 或意外元素的常见原因
调用 document.elementFromPoint(x, y) 却得不到目标热区，通常不是 API 本身有问题，而是坐标没对齐视口。这个函数只认“当前视口内的 CSS 像素坐标”，不接受页面滚动偏移、缩放、iframe 内部坐标或 clientX/clientY 未经转换的原始值。
最容易踩的坑是直接传 event.clientX 和 event.clientY —— 看似合理，但一旦页面有横向滚动条（document.documentElement.scrollLeft > 0）或使用了 transform: scale()，结果就会错位。更隐蔽的是 iframe 场景：跨 frame 调用时，必须在目标 iframe 的 document 上调用，不能在顶层 document 上查子 frame 里的元素。
- 确保
x、y是相对于当前 document 视口左上角的坐标（即pageX - scrollX，pageY - scrollY） - 若页面有 CSS 缩放，需先用
getBoundingClientRect()反推缩放后的坐标，或改用elementFromPoint配合getScreenCTM()（SVG 场景） - 检测前加
if (!document.elementFromPoint) return，IE11 及以下不支持该方法
热区重叠时如何优先命中指定容器
当多个可交互元素堆叠（比如图标覆盖在卡片上、tooltip 浮层盖住按钮），elementFromPoint 默认返回 z-index 最高且最靠近坐标的那个，但有时你希望“忽略浮层，只查底层业务区域”。这时候不能靠删 DOM 或改 z-index 临时控制，而要主动过滤。
典型做法是：先调用一次获取原始元素，再沿其 parentNode 向上遍历，检查是否属于目标热区容器（如 data-hotspot="card" 或 class 名匹配），直到找到最近的合法父容器或到达 body。避免用 querySelector 全局搜，性能差且无法反映真实层级关系。
- 用
el.closest(".hotspot-area")比循环判断更简洁，但注意 IE 不支持，需 polyfill 或降级为 while 循环 - 若热区是 SVG 元素，
elementFromPoint在部分浏览器中可能返回<g></g>而非具体<path></path>，需额外调用getIntersectionList()（仅 SVGElement 支持） - 不要依赖
offsetParent判断归属，它受position: fixed/absolute干扰，不可靠
高频触发时的性能与防抖取舍
鼠标移动事件（mousemove）每秒可能触发 60+ 次，每次调用 elementFromPoint 虽然开销小，但叠加 DOM 遍历和属性检查后，在低端设备或复杂 DOM 下仍可能掉帧。关键不是禁用，而是控制调用时机和范围。
纯节流（throttle）会丢帧，用户快速划过热区可能完全没响应；纯防抖（debounce）又导致悬停反馈延迟。更合理的策略是：仅在坐标较大幅度变化（Δx > 2px 或 Δy > 2px）或离开/进入新区域时才调用，其余时间复用上一次结果。
- 缓存上一次有效坐标和返回元素，用
Math.abs(x - lastX) > 2 || Math.abs(y - lastY) > 2做粗筛 - 避免在
requestAnimationFrame里反复调用 —— 它本身已按帧率执行，再套一层反而增加调度负担 - 若热区位置固定且无动画，可预先用
getBoundingClientRect()计算边界矩形，用纯数学判断（x > left && x ）替代 DOM 查询，快一个数量级
与 pointer-events: none 的协作陷阱
常有人给遮罩层设 pointer-events: none 来透传鼠标事件，以为这样 elementFromPoint 就能自然落到下面的元素上。但实际并非如此：elementFromPoint 不受 CSS pointer-events 影响，它只看 DOM 层级和 visibility/opacity，哪怕遮罩层设置了 pointer-events: none，只要它在 DOM 树中位于上方，仍会被返回。
真正想“跳过”某层，得手动排除：拿到结果后，检查 el.style.pointerEvents === "none" 或用 getComputedStyle(el).pointerEvents === "none"，然后向上找父节点，直到找到第一个 pointer-events: auto 的元素。注意，inherit 和 auto 都应视为可穿透，只有显式 none 才跳过。
- 别用
el.hasAttribute("style")判断，内联样式可能被 JS 修改，必须用getComputedStyle - 遇到
display: none或visibility: hidden的元素，elementFromPoint本就不会返回它，无需额外过滤 - 若热区含
opacity: 0但未隐藏，它仍参与命中，此时需结合getComputedStyle(el).opacity判断是否可视
真正难处理的是动态热区：比如 canvas 绘制的图形、WebGL 渲染的 3D 模型、或通过 clip-path 裁剪出的不规则区域。这些场景下 elementFromPoint 失效，必须回归到几何计算或底层渲染 API 的拾取逻辑，不能再依赖 DOM 层面的“点选”抽象。
