rectangle.contains 无法用于 html 光标边界检测，因其是 xamarin.forms 专属 api，浏览器中不可用；html 中需通过 getselection().getrangeat(0).getboundingclientrect() 获取光标矩形，并与容器矩形对比判断是否溢出。
Rectangle.Contains 方法不适用于 HTML 光标边界检测
直接说结论：Rectangle.Contains 是 Xamarin.Forms 中的 .NET API，它接收 Xamarin.Forms.Point 和 Xamarin.Forms.Rectangle，完全无法在浏览器环境调用。你在 HTML 编辑器里写 JavaScript，根本拿不到这个方法——它不在 window、document 或任何 DOM 接口中，也不是 CSS 或原生 JS 的一部分。
光标位置无法直接用 contains 判断，得靠 range + getBoundingClientRect
HTML 编辑器（如 contenteditable 或 textarea）中“光标是否溢出”本质是：当前选区（Range）的边界矩形是否完全落在编辑容器可视区域内。浏览器没提供 contains 这样的封装函数，但你可以手动做几何判断：
- 用
window.getSelection()获取选区，再调getRangeAt(0) - 对
range调用getBoundingClientRect()得到光标锚点或焦点的矩形（注意：空光标时可能返回退化矩形，宽高接近 0） - 用该矩形的
left/right/top/bottom与编辑容器的getBoundingClientRect()对比 - 关键逻辑不是“点在矩形内”，而是“矩形是否被容器裁剪”——比如
rect.left 就算横向溢出
常见误判场景和绕过方案
以下情况会让 getBoundingClientRect() 返回不可靠值，导致你以为“溢出”其实只是渲染延迟或布局未就绪：
Massive.com CLI
下载
一款AI数据处理工具，主要用于用于查询 Massive 市场数据端点的 Bash CLI 封装和 OpenClaw 技能，适用于 Codex 或 OpenClaw 代理从 shell 调用，适合需要提升相关任务效率的用户。
-
contenteditable内部有position: absolute子元素：它的光标矩形可能飞出容器，但这是合法行为，不是“溢出 bug” - 容器设置了
overflow: hidden但未设固定宽高：clientWidth/clientHeight可能为 0，getBoundingClientRect()仍返回绝对坐标，对比失效 - 光标位于换行符或零宽空格（
）附近：矩形可能偏移几个像素，建议加 2px 容差再判断 - 滚动中实时检测：必须节流，否则频繁调用
getBoundingClientRect()触发同步布局，卡顿明显
真正能响应“光标溢出”的只有 scrollWidth / clientWidth 比较，但仅限 textarea
对于 <textarea></textarea> 这类替换元素，你无法用 Range 获取光标矩形，只能退而求其次：
- 监听
scroll事件，检查textarea.scrollLeft > 0或scrollTop > 0—— 表示内容已横向/纵向滚动，光标大概率在不可见区域 - 用
textarea.selectionStart获取光标位置，配合textarea.value.substr(0, selectionStart)截取前置文本，再用canvas.measureText估算宽度（需同步字体设置） - 注意：
textarea不支持getSelection().getRangeAt(0)，别在这儿白费力气调surroundContents或contains
最常被忽略的一点：所谓“光标溢出”，90% 是因父容器缺少明确尺寸约束（比如没设 width/height 或 max-width），或子内容用了 white-space: nowrap 却没配 overflow。先检查这些，比写一堆 contains 判定逻辑更治本。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
