在富文本编辑器中集成jQuery UI Autocomplete是实现@提及、话题标签等交互的常见做法，但在IE9下这套方案经常翻车：用户刚敲几个字符，编辑器的焦点就被下拉菜单抢走，选中的文字范围丢失，最终插入的内容要么跑到页面顶部，要么直接把编辑区内容清空。这一问题的根源在于IE9对选区的实现与W3C标准不同，本文将详细分析原因并给出完整的修复方案。
一、IE9的选区模型与标准浏览器的差异
要理解问题，首先要知道IE9是一个“混血”浏览器。它同时支持旧版的TextRange对象（通过document.selection访问）和新版的DOM Range对象（通过window.getSelection()访问）。IE9中的Selection对象虽然是标准接口，但其行为在很多细节上与Chrome、Firefox不一致，最典型的一点是：当焦点离开可编辑区域时，IE9会立即丢弃当前选区的视觉状态，再次调用getSelection()时返回的范围可能已经失效。
而jQuery UI Autocomplete的工作机制恰恰会触发这个问题。当下拉菜单打开时，菜单本身是一个绝对定位的<ul>元素，Autocomplete为了监听键盘事件会尝试聚焦菜单项；即使在某些版本中没有真正转移焦点，浏览器渲染下拉菜单的过程本身也会引起选区重绘。在Chrome和Firefox中，编辑区失焦后选区对象仍然保留，插入位置不会丢；但在IE9中，一旦你在select回调里执行focus()再插入文本，取到的Range已经是空的或指向了错误的位置。
另一个坑是IE9的contenteditable属性支持并不完整。可编辑div中的换行符处理、光标定位的偏移量计算都与标准浏览器有出入，直接照搬Stack Overflow上针对Chrome写的Range代码，在IE9上几乎必然失败。因此解决方案必须分两套路径：标准浏览器走W3C Range，IE9走TextRange的bookmark机制。
二、保存选区的正确时机与实现
保存选区的时机非常关键：必须在Autocomplete的search事件触发之前、用户还在编辑区内正常输入时就把选区快照下来。很多人犯的错误是在select回调里才去取选区，那时IE9的选区早已被下拉菜单破坏，取到的只是空Range。
具体做法是监听可编辑div的input或keyup事件，在检测到触发字符（比如@）或正在输入候选词时，立即保存当前选区。对于IE9，使用document.selection.createRange()得到TextRange，再调用getBookmark()方法生成一个字符串形式的“书签”，这个书签即使在选区失效后依然可以用来恢复位置：
// 保存选区的跨浏览器工具函数
function saveSelection() {
var saved;
if (window.getSelection && document.createRange) {
// 标准浏览器路径
var sel = window.getSelection();
if (sel.rangeCount > 0) {
saved = sel.getRangeAt(0).cloneRange();
}
} else if (document.selection && document.body.createTextRange) {
// IE9的TextRange路径
saved = document.selection.createRange().getBookmark();
}
return saved;
}注意标准浏览器路径中用的是cloneRange()而不是直接保存Range引用。因为Range对象是活的，DOM变化会直接影响它，克隆一份副本才能保证后续插入操作时位置不受干扰。而IE9的bookmark本质上是一个记录了字符偏移的序列化字符串，天然就是一份快照，不存在这个问题。
还需要注意，如果编辑区内允许换行，IE9的TextRange在跨节点定位时偶尔会计算出错误偏移，稳妥的做法是保存前先把选区折叠到焦点位置（即光标处），只保存插入点而不保存选中文本的范围，这样能规避大部分偏移计算的bug。
三、在select回调中恢复选区并插入文本
当用户从下拉菜单中选中某一项时，Autocomplete触发select事件。此时编辑区已经失焦，要做的事情分三步：先把焦点还给编辑区，然后恢复之前保存的选区，最后在恢复的位置插入文本。恢复函数与保存函数严格对应：
function restoreSelection(saved, editor) {
editor.focus();
if (typeof saved === 'string') {
// IE9路径：用书签重建TextRange并选中
var textRange = document.body.createTextRange();
textRange.moveToBookmark(saved);
textRange.select();
} else if (saved && saved.select) {
// 标准浏览器路径：先清除现有选区再添加克隆的Range
var sel = window.getSelection();
sel.removeAllRanges();
sel.addRange(saved);
}
}
// Autocomplete初始化
$(function () {
var savedRange = null;
var editor = $('#editor');
editor.on('keyup', function () {
// 输入过程中持续更新选区快照
savedRange = saveSelection();
});
$('#mention-input').autocomplete({
source: availableUsers,
select: function (event, ui) {
event.preventDefault(); // 阻止默认写入input的行为
restoreSelection(savedRange, editor.get(0));
// 在光标处插入提及文本
insertAtCursor(editor.get(0), '@' + ui.item.label + ' ');
// 插入后重新保存新光标位置
savedRange = saveSelection();
return false;
}
});
});insertAtCursor的实现同样要分浏览器处理。标准浏览器可以创建一个DocumentFragment插入到Range的startContainer处，再用Range的insertNode方法；IE9则继续使用TextRange的pasteHTML方法。这里有一个细节：restoreSelection中必须先调用editor.focus()，否则IE9会拒绝恢复选区，moveToBookmark虽然不会报错，但恢复出来的选区在视觉上不生效，后续pasteHTML就会插错地方。
另外别忘了在select事件里调用event.preventDefault()。Autocomplete的默认行为会把选中值写入触发input元素，而我们的场景中触发元素往往是一个隐藏的辅助input，不阻止默认行为就会出现“编辑区插入了一份、input里又写了一份”的重复数据问题。
四、关闭菜单时的焦点处理与常见陷阱
除了select场景，还有一类容易被忽略的问题：用户按Esc或点击页面空白处关闭菜单后，编辑区的光标消失了，再次输入时光标跳到了内容开头。这是因为Autocomplete在关闭菜单时会触发close事件，某些版本会把焦点设回触发元素。解决方式是在close回调里同样恢复保存的选区：
$('#mention-input').autocomplete({
close: function () {
// 菜单关闭时把选区还给编辑区，避免光标丢失
if (savedRange) {
restoreSelection(savedRange, editor.get(0));
}
},
// 必须关闭Autocomplete自带的焦点抢夺行为
focus: function (event) {
event.preventDefault();
}
});同时建议给Autocomplete传入appendTo选项，把下拉菜单的DOM节点显式挂到编辑器容器内部。默认情况下菜单挂到body末尾，IE9对body末尾动态生成的元素做定位计算时可能受页面滚动影响出现偏移，挂到编辑器内部后菜单定位会跟随编辑器，也减少了选区被意外清除的概率。
最后总结几个排查要点：第一，确保保存选区的动作发生在任何焦点变化之前；第二，IE9路径始终走document.selection而不是window.getSelection()，混用两者是最常见的失败原因；第三，插入HTML后所有浏览器都要重新保存选区快照，否则连续插入两次@提及时第二次必然错位；第四，如果页面运行在IE9的兼容性视图下，contenteditable会直接失效，需要在响应头或meta中强制指定X-UA-Compatible为IE=edge。按以上方案处理，jQuery UI Autocomplete就能在IE9的Contenteditable div中稳定工作了。
jQuery UI AutocompleteContenteditableIE9 Range选区修改时间：2026-09-05 11:41:05