elementfrompoint 不能直接定位编辑器中确切可编辑节点，因其仅返回渲染最上层元素；需结合坐标校正（缩放、滚动、跨 iframe）与语义化下钻（caretrangefrompoint 或 dfs 遍历）才能精准获取真实文本节点或 contenteditable 元素。
elementFromPoint 本身不能直接定位 HTML 编辑器中鼠标点击的确切可编辑节点——它只返回渲染层叠最上层的元素，而编辑器真正响应输入的是 DOM 树中更深层的 textNode 或 contenteditable 内联元素。必须配合坐标校正和语义化查找才能拿到真实目标。
为什么直接调用 elementFromPoint(x, y) 在编辑器里大概率返回外层容器
富文本编辑器常见结构是 div[contenteditable] 套多层 span、strong、p，甚至嵌套 iframe。此时 elementFromPoint 返回的往往是顶层 div 或浮动工具栏遮罩，而非你点中的某个 TextNode。原因包括：
- 编辑器容器用了
transform: scale(0.85)，但clientX/clientY是原始像素，需用getBoundingClientRect()反推或除以缩放系数 - 内容区独立滚动（
overflow-y: auto），clientX/clientY是视口坐标，得减去滚动偏移：y - editor.scrollTop - 移动端
touchstart.touches[0].clientX受 pinch-zoom 影响失真，应改用touches[0].pageX - window.scrollX并限定在editor.getBoundingClientRect()范围内 - 存在
pointer-events: none的蒙层或z-index隔离的层叠上下文，导致点击穿透
拿到 elementFromPoint 结果后，如何向下找到真正的编辑节点
从顶层元素出发，不能停步，要结合编辑语义继续下钻：
- 先确认是否在编辑上下文中：
el.contentEditable === 'true'或el.closest('[contenteditable]') - 优先用
document.caretRangeFromPoint(x, y)—— 它专为编辑场景设计，返回的Range对象可通过.commonAncestorContainer直接定位到最深文本节点 - 若浏览器不支持（如 Safari 旧版本），手动 DFS 遍历子树：
跳过display: none、visibility: hidden、pointer-events: none的节点
优先匹配nodeType === 3（Text）或el.isContentEditable === true
坐标校正必须做，否则 x/y 传进去就错了
编辑器内部坐标系常与视口不一致，直接传 event.clientX 和 event.clientY 几乎必然失败：
- 若编辑器有
transform，用const rect = editor.getBoundingClientRect(); const scaleX = rect.width / editor.offsetWidth;算出缩放比，再校正：const realX = (x - rect.left) / scaleX; - 若内容区可滚动，且
editor不是根滚动容器，需获取其滚动偏移：const scroller = editor.querySelector('.content-scroller') || editor;，然后用scroller.scrollTop和scroller.scrollLeft - 跨 iframe 场景下，必须先用
IDisplayServices.TransformPoint（IE/旧 Edge）或iframe.contentWindow.document.elementFromPoint（现代）转换坐标系
真正难的不是调用 elementFromPoint，而是判断它返回的节点是否“够深”——编辑器里一个 span 可能还包着 em 再包着 TextNode，而光标位置只对最末级生效。别依赖视觉层级，要靠 Range 或 DFS 深度遍历逼近真实节点。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
