contenteditable="true"不兼容浏览器，因Chrome回车插<div>、Firefox插<p>、Safari连续Enter可能清空段落；粘贴Word内容嵌套标签解析各异；移动端光标定位失败、软键盘遮挡、输入法延迟是常态；必须拦截paste、Enter、Backspace默认行为，并设置tabindex="0"确保聚焦与命令生效。
为什么直接加 contenteditable="true" 一定不兼容
浏览器对 contenteditable 的实现差异不是“偶尔不一致”，而是从底层就分叉：Chrome 回车插 <div>，Firefox 插 <p>，Safari 连续按两次 Enter 可能清空段落；粘贴时 Word 带来的嵌套 <div><table><tr><td> 在各端解析结果完全不同；移动端光标定位失败、软键盘遮挡、输入法上屏延迟更是常态。这些不是 bug，是规范缺失下的必然表现。
必须拦截的三个默认行为：paste、Enter、Backspace
放任浏览器处理这三件事，等于放弃控制权：
-
paste事件必须event.preventDefault()，再用event.clipboardData.getData('text/plain')提纯——哪怕你想要部分 HTML，也得自己用DOMParser解析后白名单过滤，不能直接塞innerHTML -
keydown中捕获Enter，event.preventDefault()后手动插入<p></p>或换行符\n（取决于你用textContent还是innerHTML存储） -
Backspace在段首合并段落的行为无法统一，建议监听input后调用element.normalize()合并相邻文本节点，再用正则清理空标签：el.innerHTML = el.innerHTML.replace(/<p><\/p>/g, '<p><br><\/p>')
tabindex 和 focus 状态比 contenteditable 值本身还关键
漏掉 tabindex="0"，contenteditable="true" 就是摆设——鼠标能点、能输字，但 Ctrl+B 失效、document.execCommand 报错、getSelection() 拿不到有效范围、移动端甚至不唤起键盘。更隐蔽的是父级干扰：
- 父容器写了
contenteditable="false"，子元素的true直接被忽略（“就近 false 优先”） -
user-select: none或pointer-events: none会让点击彻底无响应，连鼠标聚焦都触发不了 - 移动端需额外加
min-height: 1.5em防止光标定位失败，iOS Safari 对无tabindex元素的 focus 行为尤其脆弱
读取内容时别碰 value，textContent 和 innerHTML 要分开用
el.value 永远是 undefined，这是新手最高频的误操作。真正该用的两个 API 有明确分工：
立即学习“前端免费学习笔记（深入）”；
- 存摘要、校验长度、做搜索匹配 → 一律用
el.textContent，它干净、无标签、跨浏览器一致 - 需要保留格式（比如加粗、换行）→ 必须用
el.innerHTML，但上线前必须过滤：DOMPurify.sanitize(el.innerHTML)是底线，正则清洗仅作临时兜底：el.innerHTML.replace(/<\/?[^>]+>/g, '') - 千万别在 Vue/React 中用
v-html或dangerouslySetInnerHTML直接渲染未清洗的innerHTML，XSS 风险真实存在
真正难的不是让文字变可编辑，而是把粘贴清洗、回车语义、光标定位、移动端键盘适配、XSS 过滤这些细节全兜住——哪怕只做一个内嵌备注框，也得先处理好 paste 和 Enter；要做正式产品，contenteditable 只能当最底层开关，上层逻辑必须自己重写。
