contenteditable 仅提供可编辑能力，非富文本编辑器；需拦截粘贴、清洗HTML、安全读写值、禁用子元素交互、接管输入法与撤销栈以实现可控编辑。
contenteditable 不是富文本编辑器，它只是让元素变成可编辑区域——用错场景或不加约束，轻则格式混乱，重则 XSS 漏洞。
为什么直接设 contenteditable="true" 后粘贴 Word 内容会炸样式
浏览器对粘贴进来的 HTML 处理极不统一：Word 会塞进大量 <span style="mso-...>、嵌套 <div> 和无意义 class；Chrome 可能保留 <table>，Firefox 却转成 <p> 堆叠。更麻烦的是，onpaste 事件拿到的 clipboardData.getData('text/html') 在 Safari 下常为空，只能 fallback 到 'text/plain'。
实操建议：
- 必须拦截
onpaste，用event.preventDefault()阻止默认行为 - 手动解析粘贴内容：优先取
'text/html'，降级用'text/plain'，再用 DOMParser 清洗节点 - 禁止插入
<script>、onerror、javascript:等危险片段，推荐用DOMPurify.sanitize()处理后再insertAdjacentHTML - 避免依赖
document.execCommand()—— 它在 Chrome 90+ 已被标记为弃用，且对列表/表格等结构支持极差
contenteditable 元素里怎么安全读取和更新值
别直接读 innerHTML：用户可能删掉所有内容，导致 innerHTML === ''，但光标还在；也可能输入空格或 <br>，造成值判断失真。也别用 innerText，它会抹掉换行和缩进，且不反映实际 DOM 结构。
立即学习“前端免费学习笔记（深入）”；
实操建议：
- 读值时用
element.innerText || element.textContent获取纯文本，或用element.innerHTML.replace(/<br\s*\/?>/gi, '\n').replace(/<\/?[^>]+>/g, '')
做简易 HTML 转文本（仅限简单场景） - 写值时不要直接赋
innerHTML，而是先清空子节点：while (el.firstChild) el.removeChild(el.firstChild)，再用insertAdjacentHTML('beforeend', sanitizedHtml) - 受控组件中，每次
onInput触发后应比对innerHTML与上一次值，避免无效更新触发 React 重渲染 - 注意焦点管理：
innerHTML重置会丢失光标位置，需用getSelection().getRangeAt(0)手动保存/恢复
为什么 contenteditable 子元素设 contenteditable="false" 还能被编辑
因为 contenteditable 的继承逻辑不是 CSS 那种“子元素自动继承父级值”，而是“只要父元素可编辑，子元素就可编辑，除非显式设为 false”。但问题在于：如果子元素是 <button> 或 <input>，它们本身有原生交互行为，contenteditable="false" 并不能禁用点击或聚焦——它只禁用文本输入。
实操建议：
- 禁用子元素交互，得组合使用：
contenteditable="false"+tabIndex="-1"+pointer-events: none（CSS） - 若子元素是变量占位符（如
<span data-var="name">{{name}}</span>），需监听keydown拦截 Backspace/Delete 键，并阻止其删除整个节点 - 避免在可编辑区域里放
<iframe>、<canvas>或第三方组件，它们可能劫持事件或破坏选区
React 中封装 contenteditable 组件最容易漏掉的三件事
很多人照着示例写个 div[contentEditable] 就完事，结果上线后发现：输入中文时失焦、Ctrl+Z 不生效、光标乱跳。根本原因在于没接管底层编辑生命周期。
实操建议：
- 必须监听
onCompositionStart/onCompositionEnd，在输入法组合期间暂停onInput值同步，否则中文输入中途会触发错误更新 - 撤销栈不能只靠浏览器原生（
document.execCommand('undo')已废弃），得自己维护一个historyStack: string[]，每次有效onInput后 push 当前innerHTML - ref 绑定必须用
useRef+useEffect手动同步 props.value 到 DOM，不能只靠dangerouslySetInnerHTML—— 否则父组件强制更新时，光标会跳到开头
真正难的从来不是让文字可编辑，而是让编辑过程可控、可预测、可审计。哪怕只支持加粗和换行，也要想清楚：粘贴进来算谁的？撤销到底撤哪一步？用户删了整段，数据模型该留空还是留默认占位符？这些细节不提前定义，后期补救成本远高于从零写个小型 Slate 插件。
