点得中需验证event.target是否为预期元素，仅靠getboundingclientrect()不够，必须用elementfrompoint()采样中心及四角坐标并检查el.contains(result)，注意iframe/shadow dom上下文切换。
元素在可点击区域，不等于“点得中”，而要看 event.target 是否是你预期的那个元素——很多视觉上能点中的地方，实际触发的是父级、伪元素或空白文本节点。
用 getBoundingClientRect() + elementFromPoint() 验证真实热区
仅靠 getBoundingClientRect() 只能知道元素几何位置，不能判断是否被遮挡或是否真正响应点击。必须配合 elementFromPoint() 在关键坐标采样：
- 取元素矩形的中心点：
const { left, top, width, height } = el.getBoundingClientRect(); const x = left + width / 2; const y = top + height / 2; - 调用
document.elementFromPoint(x, y)，检查返回值是否为el或其后代（el.contains(result)） - 为防边缘失效，建议额外采样四角（
left, top；right, top；left, bottom；right, bottom），任一点命中即算有效热区 - 注意：
elementFromPoint()在 iframe 或 Shadow DOM 中需切换上下文调用，否则始终返回 null
排查常见热区漂移原因
热区“看起来能点中但点错了目标”，90% 源于以下三类 CSS/HTML 问题：
-
line-height过大导致<a></a>或<label></label>底部多出不可见热区——加vertical-align: top或改用display: block -
padding直接扩大热区，margin不会；但若父容器设了overflow: hidden且子元素 padding 溢出，可能被裁剪又意外触发 -
touch-action: none在 iOS Safari 中会让<label></label>文字点击完全静默，即使elementFromPoint()显示命中也无事件 - 非法嵌套：如
<button><a>xxx</a></button>，浏览器会自动“修复” DOM，把<a></a>提到 button 外，但事件监听仍绑在原位置，造成热区错位
真机测试时必须验证的两个信号
桌面端开发者工具高亮热区再准，也不代表移动端可用：
- iOS Safari 中点击
<label></label>文字无反应，但点<input>本身可以 → 优先查touch-action: none是否作用于祖先节点 - 两个按钮之间“缝隙”能跳转，尤其缩放后更明显 → 检查是否用了
padding模拟间距（应改用gap或margin） - 滚动后部分区域突然不可点 → 很可能是
transform: translateZ(0)或will-change创建了新层叠上下文，导致elementFromPoint()返回错误祖先
热区问题最难调试的地方在于：它不报错、不抛异常，只悄悄把点击发给别的元素。每次怀疑热区不准，就别猜，直接用 elementFromPoint() 在真机上打点验证——哪怕只测中心点，也比凭感觉调样式可靠得多。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
