Node.contains不能检测选区是否溢出边界容器，它仅判断节点后代关系；真正需用getBoundingClientRect()对比坐标，结合Selection、Range和DOMRect手动推导可视性。
contains 方法本身不能检测选区是否溢出边界容器——它只判断节点归属关系，不处理几何位置。真正需要的是 getBoundingClientRect() 与容器矩形的坐标比对。
Node.contains 只能判断节点是否在容器内，不是“溢出检测”
很多人看到 contains 就以为能用来做“光标/选区是否还在编辑器里”，但这是误用。Node.contains() 接收一个 DOM 节点，返回 true 仅表示该节点是调用者的后代（包括文本节点、注释节点等），和屏幕位置、滚动、裁剪完全无关。
- 即使光标已滚动到容器可视区外，只要它还在
contenteditable元素内部（比如一个隐藏在overflow: hidden下的span里），editor.contains(event.target)仍返回true - 若用户点击了编辑器内一个
position: absolute的浮动工具栏，它视觉上“飞出去”了，但 DOM 层级仍在编辑器下，contains依然为true—— 这不是 bug，是预期行为 - 它对
Range对象无效：editor.contains(range)必然报错，因为Range不是Node
真正检测“选区是否溢出”的核心是 getBoundingClientRect() 坐标对比
浏览器没提供“选区是否可见”的封装 API，但你可以从 Selection + Range + DOMRect 手动推导：
- 用
window.getSelection()获取当前选区，再调.getRangeAt(0)得到首个Range - 对
range调用.getBoundingClientRect()，得到一个DOMRect对象（注意：空光标时宽高可能接近 0） - 用
editor.getBoundingClientRect()获取编辑容器的可视区域矩形 - 对比关键边界：
rect.left 或 <code>rect.right > editorRect.right或rect.top 等，任一成立即视为横向或纵向溢出 - 建议加 ±2px 容差，避免因字体渲染、零宽字符导致的像素级偏移误判
textarea 是个例外：不能用 getBoundingClientRect() 获取光标矩形
textarea 是替换元素，其内部没有 DOM 子树，getSelection().getRangeAt(0) 在它上面会失败。此时只能退而求其次：
立即学习“前端免费学习笔记（深入）”；
- 监听
scroll事件，检查textarea.scrollLeft > 0或textarea.scrollTop > 0—— 表示内容已滚动，光标大概率不可见 - 用
textarea.selectionStart获取光标位置，配合textarea.value.slice(0, selectionStart)截取前置文本，再用canvas.measureText()估算光标所在行的水平偏移（需同步字体、字号、letter-spacing 等样式） - 不要依赖
textarea.clientWidth和scrollWidth的简单比较：当overflow: visible时，clientWidth可能等于scrollWidth，导致误判
容易被忽略的性能与时机陷阱
频繁调用 getBoundingClientRect() 会强制触发同步布局（layout thrashing），尤其在滚动中实时检测时卡顿明显：
- 必须节流：用
requestIdleCallback或debounce（300ms 以上）包裹检测逻辑 - 避免在
input或keyup中直接调用——这些事件太密，且光标位置未必已更新完成 - 推荐在
selectionchange事件后延迟执行，或结合ResizeObserver监听容器尺寸变化后再检测 - 如果编辑器用了虚拟滚动或懒加载，要确保目标节点已真实挂载，否则
getBoundingClientRect()返回{ width: 0, height: 0 }
真正难的不是写对那一行 rect.left > editorRect.right，而是搞清你到底想定义什么是“溢出”：是视觉不可见？是无法通过键盘导航到达？还是滚动条已出现？不同定义对应完全不同的检测路径，别让 contains 这个名字把你带偏了。
