caretRangeFromPoint 在拖拽时大多失效，因现代浏览器仅允许在用户手势同步栈中调用，mousemove/dragover 中调用会返回 null 或抛出 NotAllowedError。
Document.caretRangeFromPoint 本身不能直接用于拖拽定位——它只在点击/触摸瞬间有效，且在拖拽过程中鼠标持续移动，坐标频繁变化，而该 API 在多数浏览器中对非用户触发的调用（如 mousemove 中反复调用）会返回 null 或抛出安全错误。
为什么 caretRangeFromPoint 在拖拽时大多失效
现代浏览器（Chrome ≥ 84、Firefox ≥ 79、Safari ≥ 15.4）已限制该 API 的调用上下文：仅允许在用户手势（mousedown、touchstart、click 等）的同步执行栈中调用。一旦进入 mousemove 或 dragover 回调，就超出许可范围。
常见错误现象：
– 拖拽时反复调用 document.caretRangeFromPoint(x, y) 返回 null
– 控制台报错 NotAllowedError: caretRangeFromPoint can only be called from a user gesture
实操建议：
• 不要在 mousemove 中调用 caretRangeFromPoint
• 避免用它实现“实时光标吸附”类交互
• 若仅需一次定位（如拖拽开始时确定插入点），可在 mousedown 或 dragstart 中调用并缓存结果
立即学习“前端免费学习笔记（深入）”；
替代方案：用 document.elementFromPoint + 文本节点遍历
这是目前最稳定、跨浏览器兼容的拖拽定位思路：先用 elementFromPoint 找到目标元素，再判断是否为可编辑文本容器，最后通过 range.getBoundingClientRect() 或 getBoxQuads() 匹配光标位置。
使用场景：富文本编辑器中拖拽一个块元素（如图片、卡片）到段落中间插入
实操建议：
• 在 dragover 中调用 document.elementFromPoint(x, y) 是完全安全的
• 对返回元素向上查找 contenteditable="true" 或 designMode === "on" 的祖先
• 若目标是 Text 节点，用 document.caretPositionFromPoint（Chrome/Firefox 支持，但 Safari 仍不支持）或手动二分查找文本偏移量
• 示例：获取鼠标下方最近的文本行，再用 Range 插入占位符标记插入点
真实可用的拖拽插入点检测代码片段
以下逻辑在 Chrome/Firefox/Safari（≥16.4）中均能工作，不依赖 caretRangeFromPoint：
editor.addEventListener('dragover', (e) => {
const el = document.elementFromPoint(e.clientX, e.clientY);
if (!el || !el.closest('[contenteditable="true"]')) return;
const range = document.createRange();
const rect = el.getBoundingClientRect();
// 粗略定位：插入点设在元素左边缘垂直居中处
range.setStart(el, 0);
range.collapse(true);
// 更精确做法：遍历子 Text 节点，找 clientY 最近的行
// 此处省略二分逻辑，实际项目中建议封装为 findInsertOffset(el, e.clientX, e.clientY)
});
性能影响：
• elementFromPoint 开销极小，可放心在 dragover 中调用
• 遍历文本节点做行级定位需节流（如 throttle(16ms)），否则影响拖拽流畅度
• 避免在每次 dragover 中重建 Range 并调用 getBoundingClientRect() 多次
移动端适配与 Safari 特别注意
Safari 对 caretRangeFromPoint 的限制最严格，且不支持 caretPositionFromPoint；iOS 上 dragover 事件默认不触发，必须显式设置 draggable="true" 和监听 touchmove 模拟。
容易踩的坑：
• Safari 中 elementFromPoint 在 iframe 内容中可能返回 null，需确保同源且 iframe 已加载完成
• iOS Safari 的 clientX/clientY 在 touchmove 中需取 touches[0]，而非 changedTouches[0]
• 所有基于坐标的定位，务必考虑缩放（window.visualViewport?.scale）和滚动偏移（window.scrollY）
复杂点在于：真正的“拖拽中光标精准定位”不是单个 API 能解决的，它需要结合 DOM 结构分析、文本流布局推断、以及针对不同浏览器的 fallback 策略。很多编辑器最终选择放弃像素级定位，转而高亮目标块级容器（如段落、列表项），让用户松手后由程序决定插入位置。
