contenteditable是HTML原生属性，设为true后使元素可编辑，但不能直接当富文本编辑器用——因无格式模型、粘贴不可控、Enter产出不一致、存在XSS风险。
contenteditable 是什么，为什么不能直接当富文本编辑器用
contenteditable 是 HTML 原生属性，设为 true 后，div、span 甚至 p 都能像 textarea 一样输入文字。但它本质只是“开启浏览器默认编辑行为”，不是富文本编辑器——没有统一的格式模型、不隔离用户粘贴的样式、不控制 Enter 键产出的标签（Chrome 插 div，Firefox 插 br），更不会自动过滤 XSS 风险的 HTML 片段。
如何让 contenteditable 元素真正可用（基础加固）
光加 contenteditable="true" 远不够，至少要补这几点：
- 显式设置
tabindex="0"，否则键盘焦点可能无法进入，尤其在非表单上下文中 - 用 CSS 重置默认编辑样式：
user-select: text防止误选整块，outline: none配合自定义 focus 状态，white-space: pre-wrap保留换行和空格 - 监听
input事件而非change（后者不触发），获取实时内容用element.innerHTML，但注意它包含标签——如果只要纯文本，得用element.innerText或element.textContent - 禁止粘贴富文本干扰：监听
paste事件，调用event.preventDefault()，再用event.clipboardData.getData('text/plain')取纯文本插入
常见 DOM 操作陷阱与绕过方式
用户编辑时，浏览器会悄悄修改 DOM 结构，比如把空行渲染成
<br>
，或把连续空格转成 。直接读 innerHTML 会拿到这些“脏数据”：
- 插入图片或链接后，
img或a标签可能带内联style，甚至含data-属性，不同浏览器行为不一致 -
document.execCommand已废弃，别依赖它做加粗/列表等操作；现代方案是用Selection+RangeAPI 手动包裹节点，或用document.execCommand('insertHTML', false, 'xxx')（兼容性尚可，但 Chrome 98+ 已警告） - 清空内容别用
element.innerHTML = ''，会导致焦点丢失；应改用element.textContent = ''，再手动聚焦
安全与数据落地必须做的两件事
用户可任意输入 HTML，innerHTML 直接存库或渲染会引发 XSS。不能只靠后端过滤：
- 前端存数据前，必须净化 HTML：用
DOMPurify.sanitize(element.innerHTML)（轻量、主动维护），不要自己正则匹配<script></script> - 服务端接收时仍需二次校验：至少剥离所有
on\w+=、javascript:、data:text/html类属性和协议，且限制允许的标签白名单（如仅strong,em,ul,li）
复杂点在于：用户粘贴 Word 内容时，会带大量冗余 style 和嵌套 span，DOMPurify 默认不清理内联样式，得配 {ALLOWED_ATTR: ['class']} 并额外 strip style 属性——这点容易被忽略。
