HTML选区优化与文本操作技巧

本文深入解析了HTML中选区（Selection）与文本操作的核心难点，涵盖getSelection()返回空实例的规范原因及应对策略、Range API修改文本时光标错位的根源与精准控制方法、contenteditable中自定义replaceText()失效的三大陷阱、iOS Safari特有的Selection行为差异，以及真实项目中判断“可安全操作选区”的关键检查项——帮助开发者避开浏览器兼容性雷区，写出稳定可靠的富文本交互逻辑。

getSelection() 返回的对象为什么经常是 null？

页面没聚焦或选区在 iframe 里时，getSelection() 会返回空对象（实际是空 Selection 实例，但 toString() 为空、rangeCount 为 0）。不是 bug，是规范行为。

• 确保目标元素已获得焦点（比如 contenteditable 元素需先 focus()）
• 跨 iframe 操作必须在同源前提下，且显式访问 iframe.contentDocument.getSelection()
• 监听 selectionchange 事件比轮询更可靠，但注意该事件不冒泡，需在 document 上监听

Range API 修改文本时为何光标乱跳或内容错位？

直接用 range.deleteContents() 或 range.insertNode() 后未重置光标位置，浏览器会按默认策略恢复选区——通常落在修改后节点末尾，而非你期望的位置。

• 操作前用 range.cloneRange() 备份起始/结束位置（特别是 startOffset 和 endOffset）
• 插入文本优先用 range.insertNode(document.createTextNode('xxx'))，而非 innerHTML；后者会触发重排，干扰选区计算
• 操作完成后调用 selection.removeAllRanges() 再 addRange() 恢复，避免残留 range 影响后续判断

contenteditable 中 replaceText() 不生效的三个常见原因

原生没有 replaceText() 方法，多数人是自己封装，但容易忽略 DOM 结构碎片化问题——比如选区横跨 和文本节点，range.toString() 虽能读出完整文本，但 range.commonAncestorContainer 可能只是父