应避免使用 document.execcommand() 插入列表，因其在 chrome、firefox、safari 中行为不一致，且在 contenteditable="false" 环境下静默失败；推荐手动 dom 操作构建 ul/ol 结构以确保可控性与稳定性。
直接用 document.execCommand() 插入列表最简单，但浏览器行为不一致、生成的 HTML 结构不可控，生产环境慎用。
为什么 insertUnorderedList 和 insertOrderedList 会出错
这两个命令在不同浏览器中触发逻辑差异大：Chrome 可能对空行插入 <ul><li><br></li></ul>，Firefox 可能包裹已有段落为 <li> 却漏掉父容器，Safari 甚至拒绝在非段落块内执行。更麻烦的是，若光标位于 <p></p> 内部但该 <p></p> 已被 contenteditable="false" 父元素限制，命令直接静默失败 —— 不报错，也不生效。
常见错误现象包括：
- 点击按钮无反应（尤其在嵌套 div 或表格单元格里）
- 列表项文字消失，只剩空
<li> - 原有段落被拆成多个孤立
<li>，丢失语义层级 - 撤回（
undo）后结构错乱，无法恢复原状
怎么让列表插入真正可控
绕过 execCommand，改用 DOM 操作手动构建结构。核心是获取当前选区（getSelection()），定位到最近的可编辑文本节点，再根据需求包裹或替换为 <ul></ul>/<ol></ol>。
实操建议：
- 先用
selection.getRangeAt(0)获取光标位置，再调用range.commonAncestorContainer找到最近的可编辑祖先 - 若选区跨多段，遍历所有包含文本的
<p></p>或<div>，逐个提取文本并新建 <code><li> - 用
document.createElement('ul')创建容器，appendChild插入新<li>，再用range.deleteContents()清空原内容，最后range.insertNode()插入新结构 - 避免直接操作
innerHTML，防止 XSS 风险和格式丢失；插入后手动聚焦新<li>的末尾，保持光标可用 - 给工具栏按钮绑定事件时，检查当前光标是否已在
<ul></ul>或<ol></ol>内部，如果是，优先执行「新增<li>」而非「创建新列表」 - 用 CSS 强制重置：
ul, ol { margin: 0; padding-left: 24px; }，并确保li::marker可见 - 对已存在的列表，监听
keydown事件，拦截Backspace在第一个<li>开头时的行为，防止误删整个<ul></ul> - 禁止用户粘贴纯文本进列表项时自动换行生成新
<li>—— 这需要拦截paste事件并规范化粘贴内容
contenteditable 区域里列表的样式和语义陷阱
默认情况下，<ul></ul> 和 <ol></ol> 在 contenteditable 中没有缩进或项目符号渲染，因为浏览器重置了部分 UA 样式。更关键的是，很多富文本场景要求「列表可编辑但不可删除整个容器」——比如用户只能修改 <li> 文本，不能删掉 <ul></ul> 标签本身。
解决方法：
真正难的不是插入列表，而是让列表在编辑、粘贴、撤回、协作光标等场景下不崩坏。DOM 手动构造比 execCommand 多写 3 倍代码，但换来的是可预测的 HTML 输出和稳定的交互反馈。
