splitText() 是原生 DOM API，只能在已挂载的纯文本节点上操作；富文本编辑器中因节点被包裹、切碎或锁定，直接调用会失败，需手动遍历 DOM 定位可写 textNode 并谨慎处理光标与后续同步。
splitText() 不是编辑器功能，它是原生 DOM API，只能在已挂载的文本节点上操作。直接在富文本编辑器（如 Quill、TinyMCE）或 contenteditable 区域里调用会失败——因为那些区域通常由多层 wrapper、span、br 或空格占位符构成，真实文本节点被包裹或切碎了。
为什么 splitText() 在编辑器里常“找不到目标节点”
富文本编辑器几乎从不让你直接操作裸文本节点：document.createTextNode() 生成的节点极易被编辑器内部机制自动合并、替换或丢弃。你看到的一段文字，背后可能是 3 个 textNode + 2 个 br + 若干 span 样式包裹体。调用 node.splitText(5) 前必须确认 node 确实是纯文本节点且未被编辑器锁定。
- 用
getSelection().anchorNode拿到的节点，大概率是Element（比如p或span），不是Text - 即使选中纯文本部分，
anchorNode.nodeType === Node.TEXT_NODE也不一定为true；很多编辑器会插入零宽空格（\u200B）或zwnj来维持光标位置，导致实际节点含不可见字符 -
splitText()只作用于当前文本节点，不能跨标签、不能跨父子关系——它不会帮你把<p>abc<em>def</em>ghi</p>中的 “def” 单独拆出来
如何安全获取并拆分可编辑区域中的目标文本节点
必须绕过编辑器抽象层，手动遍历 DOM 并过滤出真正可写的纯文本子节点。关键步骤：
- 先定位光标所在最深层元素：
const el = window.getSelection().anchorNode.parentElement，再用el.childNodes遍历 - 对每个子节点检查：
node.nodeType === Node.TEXT_NODE && node.textContent.trim() !== "" - 找到目标后，确保它没被编辑器标记为只读（例如某些编辑器会给节点加
data-ql-block="true"或contenteditable="false"） - 拆分前保存光标位置（用
Range记录 offset），否则拆完节点后光标会丢失或跳转 - 拆分后立即用
Range.setStart(nodeAfterSplit, 0)重置光标，否则用户无法继续输入
局部标注的实际替代方案：别硬拆文本节点
想实现“给一段文字中某几个字加高亮/注释”，splitText() 是高危路径。更稳定的做法是包裹而非切割：
立即学习“前端免费学习笔记（深入）”；
- 用
document.execCommand("insertHTML", false, "<mark data-note='id123'>xxx</mark>")（注意：已废弃但多数编辑器仍支持） - 手动创建
mark或span元素，用Range.surroundContents()包裹选中文本（需先range.deleteContents()） - 若需保留原始文本结构，优先用
data-属性标记范围，比如在父容器上记录data-highlight='[{"start":12,"end":18,"note":"术语"}]'，渲染时动态插入mark - 避免在
contenteditable内部直接操作splitText()后的节点——它们极易被编辑器的 change handler 重新 normalize 掉
真正难的不是拆分动作本身，而是让拆分结果在编辑器后续的格式化、undo/redo、协作光标同步中存活下来。绝大多数编辑器对裸 Text 节点变更无感知或主动修复，所以标注逻辑最好完全基于元素级包裹和元数据驱动。
