Selection API 返回 null 主因是调用时机不当：需确保 contenteditable 元素已聚焦，且避免在 input/textarea 中使用；插入纯文本应转义换行符并用 createTextNode；插入后须手动重置光标位置。
Selection API 获取光标位置为什么总是返回 null
多数情况下不是 API 本身失效，而是调用时机不对——document.getSelection() 在用户未聚焦编辑区域、或目标元素未设置 contenteditable="true" 时会返回空对象。更隐蔽的问题是：在 input 或 textarea 中无法用 Selection API 直接操作，必须改用 selectionStart/selectionEnd；只有 div[contenteditable] 这类富文本容器才真正走 Selection API 流程。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 确保插入点容器有
contenteditable="true"属性，且已获得焦点（调用element.focus()） - 不要在事件捕获阶段读取 selection，优先用
setTimeout(() => { ... }, 0)或监听selectionchange事件 - 检查
getSelection().rangeCount === 0，为真时说明当前无有效选区，需 fallback 到光标所在节点的末尾插入
如何把代码段作为纯文本插入到光标处而不破坏格式
直接用 range.insertNode() 插入带标签的代码块容易引发嵌套混乱，比如在 <p> 内插入 <pre><code> 可能被浏览器自动补全或拆分。更稳妥的做法是插入预格式化文本，并手动控制换行与缩进。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 用
document.createTextNode()创建纯文本节点，对换行符做\n→\u200B\n处理（零宽空格防合并），再插入 - 若需保留语法高亮，插入后立即用
Prism.highlightElement()或类似工具处理该<code>节点 - 避免用
innerHTML += ...，这会重置整个容器的 selection 状态
insertNode 后光标跳到末尾或丢失的修复方法
这是最常被忽略的副作用：range.insertNode() 不会自动更新光标位置，浏览器默认将光标置于插入内容之后，且若插入的是孤立文本节点，可能脱离原有段落结构导致 selection 崩溃。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 插入前用
range.getClientRects()记录原始光标坐标（仅作参考），插入后用range.collapse(false)将光标移至新节点末尾 - 更可靠的方式是：插入后创建新 range，定位到新节点最后一个文本子节点的末尾，再用
window.getSelection().removeAllRanges()+.addRange() - 若插入的是多行代码，务必确保父容器支持
white-space: pre-wrap，否则换行符会被忽略
兼容性陷阱：Firefox 和 Safari 对 Range 的处理差异
Firefox 在 contenteditable 中对 range.commonAncestorContainer 的返回值更严格，可能指向 body 而非实际编辑容器；Safari 则常在插入后丢弃 range.collapsed 状态，导致后续插入错位。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 不依赖
commonAncestorContainer判断上下文，改用range.startContainer.parentElement.closest('[contenteditable]') - Safari 下插入后强制执行一次
getSelection().collapseToStart()再重新定位 - 所有 range 操作前加
if (!range || !range.startContainer)防御性判断，尤其在异步回调中
真正难的不是插入代码段，而是让光标在各种浏览器、各种嵌套层级下都稳稳停在该停的位置——每次插入后都要重置 selection，而不是假设它还在原地。
