contenteditable仅提供基础可编辑能力，不内置格式控制、行为不一致、粘贴污染严重、execcommand已废弃、光标选区易错、innerhtml不可靠，需手动清洗和接管paste事件。
contenteditable 本身不能让网页变成真正可用的富文本编辑器——它只打开一扇门，但门后没有路标、没有导航、也没有刹车。
contenteditable 的真实能力边界在哪里
contenteditable="true" 只是告诉浏览器：“这个元素的内容允许用户直接输入和删改”，它不提供任何格式控制逻辑，也不保证行为一致：
- 不同浏览器对回车键的处理完全不同：
Enter在 Chrome 生成<p></p>，在 Safari 可能生成<div>，Firefox 有时还插空 <code><br> - 粘贴 Word 或微信内容时，会原样带入嵌套
<span style="font-family: Calibri"></span>、无意义<p></p>、甚至 base64 图片 -
document.execCommand()已被标准废弃，Chrome 98+ 开始禁用部分命令（如insertHTML在某些上下文中静默失败） - 光标选区（
Selection+Range）在跨块节点（比如选中两个<p></p>中间的文字）时极易出错，range.toString()返回空字符串是常见现象 -
innerHTML会暴露所有原始污染标签：Word 粘贴进来的<roundrect></roundrect>、微信的<section></section>、甚至<script></script>标签（如果没做服务端过滤） - 浏览器自动补全的结构不可控：连续按两次
Enter后，Chrome 可能生成<p><br></p> <p><br></p>，而 Safari 是<div><br></div> <div><br></div> - 语义丢失严重：
<b></b>和<strong></strong>混用、<font color="#ff0000"></font>这种过时写法照单全收 - 空内容判断失效：用户清空编辑器后，
innerHTML可能是"<br>"、"<p><br></p>"或空字符串，各浏览器不统一 - 绑定
editor.addEventListener('paste', handlePaste) - 第一时间
event.preventDefault()，否则浏览器会把原始 HTML 直接塞进去 - 用
event.clipboardData.getData('text/html')拿到原始片段（注意：纯文本粘贴时返回空，需 fallback 到'text/plain'） - 用
new DOMParser().parseFromString(html, 'text/html')解析，再遍历子节点过滤 - 最后用
range.insertNode()插入清洗后的节点，而不是execCommand('insertHTML')
你看到的“能加粗、能列列表”，其实是靠一堆 execCommand 补丁堆出来的幻觉，不是底层能力。
为什么直接读取 innerHTML 是危险又不可靠的
很多人以为给 contenteditable 元素加个 oninput 监听，再取 editor.innerHTML 就完事了。实际踩坑点密集：
真正导出前必须走清洗流程：用 DOMParser 解析、递归遍历、白名单标签、内联样式转 style 属性、移除孤立 <br>。
paste 事件必须 preventDefault() 手动接管
默认粘贴行为是富文本编辑器失控的头号源头。想保留干净结构，就得自己处理：
漏掉 preventDefault()，等于把消毒水倒进下水道——后面所有清洗都白干。
真正的难点从来不是“怎么让字变粗”，而是“用户 Ctrl+V 粘贴一段带表格的微信公众号文章后，还能不能正确识别段落、保留图片、去掉所有 data-* 属性，并且不崩光标”。这些边界 case 没有银弹，只能靠持续打磨输入层、格式层、输出层三者的配合。
