contenteditable 仅提供基础编辑能力，不支持格式控制、撤销、安全粘贴等高级功能，适合轻量场景；真富文本需用 Slate/Lexical 等底层自研方案。
contenteditable 属性开箱即用，但不是“编辑器”
直接给元素加 contenteditable="true" 确实能立刻获得光标、选区、基础输入能力，比如改标题、填表单草稿。但它只提供 DOM 层面的编辑入口，不处理格式、撤销、粘贴净化、协作光标、历史记录这些——这些得自己补。
常见错误现象：document.execCommand 在现代浏览器中已废弃，且行为不一致；直接监听 input 事件拿不到格式变化（如加粗后删掉文字，样式残留）；粘贴富文本时 HTML 被原样插入，可能带恶意 script 或乱样式。
- 使用场景适合：轻量备注、可编辑卡片标题、临时草稿框（无格式要求）
- 不适合：邮件编辑、文档协作、CMS 后台富文本录入
- 性能影响小，但若在大量
contenteditable元素上监听mutationobserver监控变化，容易卡顿
HTML 编辑功能弱，根源在语义与 DOM 的错位
HTML 是描述性标记语言，不是编辑模型。比如 <strong>hello</strong> 和 <span style="font-weight:bold">hello</span> 在渲染上一样，但 DOM 结构不同，contenteditable 无法统一抽象为“加粗”操作。浏览器对同一语义（如“斜体”）会产出不同 HTML，导致保存/同步困难。
更麻烦的是：用户用 Backspace 删除一个 <p> 段落末尾，有些浏览器会把下一段合并进来，有些则留下空 <p>；拖拽图片插入位置不可控；execCommand('insertImage') 插入的 <img> 标签没有 alt，无障碍不达标。
立即学习“前端免费学习笔记（深入）”；
- 参数差异：Chrome 倾向用语义标签（
<em>），Firefox 更爱<span>+style - 兼容性影响：iOS Safari 对
contenteditable的 focus/selection API 支持残缺，getSelection()常返回 null - 不能依赖
innerHTML当“内容快照”——它含浏览器自动补全的标签（如<div><br></div>），和真实意图偏差大
真要自研，得绕过 contenteditable 做底层控制
主流方案（如 Slate、Lexical、ProseMirror）都不直接用 contenteditable 当主容器，而是用它做“输入靶心”，所有编辑逻辑走自定义数据结构（如 JSON AST），DOM 只负责渲染，输入事件被拦截后转成命令再更新状态。
例如用户按 Ctrl+B，不调 execCommand，而是：捕获按键 → 计算当前选区对应节点路径 → 更新内存中的 schema → 触发重渲染 → 同步光标位置。这样格式、撤销、协同都可控。
const editorState = {
type: "doc",
children: [
{ type: "paragraph", children: [
{ type: "text", text: "hello" },
{ type: "text", text: "world", marks: ["bold"] }
]}
]
};
- 必须自己实现：光标定位（
range.setStart()易失效）、粘贴解析（event.clipboardData.getData('text/html')需白名单过滤）、键盘快捷键映射 - 移动端需额外处理：iOS 键盘唤起后
scrollIntoView失效，得用scrollTo({ behavior: 'smooth' })+ 定时重试 - 服务端存的不该是 HTML 字符串，而应是上述 JSON 结构或 Markdown，避免 XSS 和渲染歧义
别低估“纯文本编辑”的隐藏成本
哪怕只要支持换行+粗体+链接，也会撞上：链接点击跳转与编辑模式冲突、双击选词触发浏览器默认菜单干扰、屏幕阅读器读不出“已加粗”状态、Ctrl+Z 在嵌套 contenteditable 中失效。
真正省事的方案，是明确需求边界。如果只需要用户改几段说明文字，用 textarea + Markdown 预览更稳；如果必须所见即所得，直接集成 tiptap（基于 ProseMirror）比魔改 contenteditable 少踩三个月坑。
最容易被忽略的一点：所有基于 contenteditable 的方案，都无法可靠支持 IME（中文输入法）在复杂嵌套节点中的光标同步——这是 Chromium 和 WebKit 长期未修复的底层限制。
