contenteditable不是“加了就能用”的开关，而是需显式设为true、配合tabindex="0"聚焦、拦截paste/keydown事件、用MutationObserver监听并清洗HTML的可控编辑入口。
contenteditable 不是“加了就能用”的开关，而是浏览器原生编辑能力的入口——开对了，3 行 HTML 就能跑；开错了，回车变 <div>、粘贴带 <script>、移动端点不聚焦，全是你没管住的副作用。
contenteditable 值怎么设才不被继承覆盖
它只认四个值：true、false、inherit 和空字符串（等价于 true）。写成 contenteditable="on" 或 contenteditable="1" 是无效的，浏览器当它不存在，退化为 inherit，结果可能意外继承父级的 false 而整个不可编辑。
常见踩坑场景：
- 父容器写了
contenteditable="false"，子元素即使显式写contenteditable="true"也无效（“就近 false 优先”） - 只写
contenteditable（无等号无值），在旧版 Safari 中行为不稳定 - 误用
plaintext-only：这不是标准值，Chrome/Firefox 直接忽略，Safari 可能报错
稳妥做法：显式写 contenteditable="true"，并确保其所有祖先节点都没锁死为 false。
立即学习“前端免费学习笔记（深入）”；
为什么点了能编辑，但键盘按 Tab 进不去
因为 <div>、<p> 等非表单元素默认不可被键盘聚焦，contenteditable 不会自动给它们加 tabindex。
必须手动补上：
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
-
tabindex="0"：让它按 DOM 顺序进入 Tab 链（推荐） -
tabindex="-1"：只能用 JS 调用el.focus()聚焦，不能靠键盘切换
漏掉这步，用户点鼠标能打字，但 Ctrl+B、Ctrl+I 等快捷键完全没响应——因为没焦点，document.execCommand 和 Selection API 全部失效。
粘贴、回车、删除这些行为为什么总失控
contenteditable 的“富文本”本质是浏览器把用户操作映射成 HTML 片段，不是纯文本流。所以：
- 回车在 Chrome 插入
<div>，Safari 插入<p>，Firefox 插入<br>—— 语义不一致 - 粘贴 Word 或网页内容，会带入
<style>、<meta>甚至<script>（XSS 风险） - 删到块开头时，相邻
<p>可能被合并，或整段消失，跨浏览器行为不一致
控制手段要主动介入：
- 监听
paste事件，用event.clipboardData.getData('text/plain')提纯文本 - 拦截
keydown.enter，event.preventDefault()后调用document.execCommand('insertHTML', false, '<br>')（注意：该 API 已废弃，新项目建议用getSelection()+Range插入） - 用
MutationObserver替代已废弃的DOMSubtreeModified，监听结构变化后清洗非法标签
移动端 focus 失败和光标乱跳怎么解
移动端 Safari 对 contenteditable 的焦点管理和光标定位支持最弱：点击后键盘不弹、focus() 调用无效、光标卡在开头或消失，都是常态。
关键补救措施：
- 加
role="textbox"提升可访问性兼容性，帮 Safari 正确识别编辑意图 -
el.focus()后必须手动用Range+Selection定位光标，不能依赖默认行为 - 首次渲染后调用
focus()，需包裹在requestAnimationFrame或setTimeout(..., 0)中，避开 SSR 渲染时机问题 - 避免初始内容含空
<p></p>或嵌套<span>，这些结构容易让selectNodeContents()选中不可见节点，导致光标卡住
真正难的不是让它“能编辑”，而是守住边界：什么时候允许换行、哪些标签能留、光标该停在哪——这些细节不控，contenteditable 就只是个半成品输入框。
