node.contains 是判断点击目标是否在编辑器容器内的最轻量方式，只需确保传入真实 dom 节点、同一文档树且非 detached 或跨 iframe 节点，并配合 nodetype 检查与 contenteditable 过滤以提升健壮性。
Node.contains 判断点击目标是否在编辑器容器内
直接用 Node.contains 是最轻量、兼容性最好的方式，它不依赖事件委托或 class 名匹配，只看 DOM 层级归属。只要点击的 event.target 是编辑器容器（比如 contenteditable 的 <div id="editor">）的后代节点，就返回 <code>true。
注意：它对 shadow DOM 无效，且 Node.contains(node) 中的 node 必须是同一文档树中的节点（不能是 detached node 或跨 iframe 的节点）。
- 确保你拿到的是真实的容器 DOM 节点，不是字符串 ID 或 jQuery 对象 —— 用
document.getElementById('editor')或ref.current（React） - 不要在
mousedown或click外层监听整个document后再判断，而应在编辑器容器上监听，然后用event.target做判定 -
event.target === editor也成立，但editor.contains(event.target)更健壮（覆盖点击子元素、空隙、文本节点等场景）
避免 event.target 是 #text 或 comment 节点导致误判
点击编辑器空白处时，event.target 很可能是 #text 节点（哪怕内容为空），或者注释节点。这些节点仍属于容器后代，contains 返回 true，但后续逻辑可能因类型不符出错（比如调用 event.target.classList 报错）。
- 先做
editor.contains(event.target)判定，再检查event.target.nodeType：跳过Node.TEXT_NODE（值为3）和Node.COMMENT_NODE（值为8） - 如需操作元素属性，建议向上查找最近的元素节点：
event.target.closest('*')，再确认是否仍在editor内 - 不要用
instanceof Element直接断言 ——#text不是Element，但它是合法的Node
React / Vue 中 ref 绑定与 contains 的配合要点
框架中容易忽略 ref 尚未挂载或异步更新时机问题，导致 editorRef.current 为 null，调用 .contains() 报 Cannot read property 'contains' of null。
- React：在
useEffect中绑定事件，并确保editorRef.current存在；或在事件处理器开头加守卫：if (!editorRef.current) return - Vue 3：
onMounted后绑定，使用unref(editorRef)避免 proxy 干扰（contains在 proxy 上不可直接调用） - 不要把
editorRef当作响应式数据参与条件渲染逻辑 ——contains是纯 DOM 方法，只认原生节点
对比 click 与 mousedown：哪个时机更适合 contains 判定？
mousedown 更早触发，能捕获拖拽起点、右键菜单前的意图；click 要求鼠标按下并释放，且可能被浏览器默认行为（如选中文本后点击）延迟或取消。对“是否点在编辑器里”这个判定，两者都可，但行为目标不同。
- 要做“点击即聚焦/激活编辑器”，用
mousedown—— 用户还没松手，你就得响应 - 要做“执行某操作（如插入组件）”，用
click更稳妥，避免误触发 - 无论哪种，都建议在 handler 开头统一做
editor.contains(event.target)检查，别依赖event.currentTarget—— 它永远是绑定事件的容器，无法区分点击是否真的落在其内部
真正容易被忽略的是：当编辑器启用了 contenteditable="false" 的子区域（比如嵌入的只读卡片），contains 仍返回 true，但用户实际无法编辑那里 —— 这时候需要额外结合 event.target.contentEditable !== 'false' 或自定义 data-editable 属性过滤。
