contenteditable仅支持true、false、inherit和空字符串四值，显式写contenteditable="true"并配tabindex="0"才能确保可聚焦可编辑；父级设false会强制继承，导致子元素不可编辑。
contenteditable 是浏览器原生支持的编辑入口，不是模拟输入，而是真实参与焦点、光标和剪贴板交互——用对了，3 行 HTML 就能跑起来；用错了，回车变 <div>、粘贴带样式、移动端失焦、光标乱跳全找上门。
contenteditable 值怎么设才不踩坑
它只认四个值：true、false、inherit 和空字符串（等价于 true）。别写 "on" 或 1，这些会被当成无效值，触发 inherit 行为，结果可能意外继承父级的 false 而整个不可编辑。
常见错误场景：
- 给
<div>加了contenteditable="true"，但父容器是contenteditable="false"，子元素照样不能编辑（因为默认继承） - 写成
contenteditable（没等号没值），在部分旧版 Safari 中表现不稳定 - 误用
plaintext-only：这不是标准值，Chrome/Firefox 不识别，会退化为inherit
稳妥做法：显式写 contenteditable="true"，且确保父级没锁死编辑状态。
立即学习“前端免费学习笔记（深入）”；
为什么加了 contenteditable 还不能键盘聚焦
因为 <div>、<p> 等非表单元素默认不可被 Tab 键聚焦，即使可编辑也进不去。浏览器不会自动给它们加 tabindex。
必须手动补上：
-
tabindex="0"：让它按 DOM 顺序进入 Tab 链（推荐） -
tabindex="-1"：只能用 JS 聚焦（如el.focus()），不能靠键盘切换
漏掉这步，用户点鼠标能编辑，但键盘操作（比如按 Ctrl+B 加粗）完全没响应——因为没焦点，document.execCommand 或 Selection API 全部失效。
回车、粘贴、换行这些行为为什么不可控
contenteditable 的“富文本”本质是浏览器把用户操作映射成 HTML 片段，而不是纯文本流。所以：
- 回车默认插入
<div>（Chrome）或<p>（Safari），不是<br> - 粘贴 HTML 时会带入原始样式、
<span>、内联style，甚至脚本标签（XSS 风险） - 删除到块开头时，可能合并相邻块或删掉整个
<p>，行为跨浏览器不一致
要收口，得监听事件并干预：
- 用
@keydown.enter.prevent（Vue）或event.preventDefault()+document.execCommand('insertHTML', false, '<br>')强制换行 - 监听
paste事件，用event.clipboardData.getData('text/plain')提纯文本 - 对
input或DOMSubtreeModified（已废弃）改用MutationObserver监听结构变化，及时清洗非法标签
移动端 focus 失败和 caret-color 不生效怎么办
Android Chrome 和 iOS Safari 对 contenteditable 的焦点管理更严格：点击后不自动唤起软键盘、光标不显示、caret-color 被忽略，都是常见现象。
关键修复点：
- 确保元素有明确宽高、非
display: none或visibility: hidden，且不在transform缩放容器里 - 首次点击前，用
setTimeout(() => el.focus(), 0)延迟聚焦（iOS 必须） -
caret-color在 iOS 上仅对input/textarea可靠，contenteditable元素需配合user-select: text+-webkit-user-modify: read-write - 安卓端若光标不出现，尝试加
spellcheck="false"并禁用 autocorrect
这些不是边缘 case，而是移动端 contenteditable 的基础运行条件——没处理好，用户点半天没反应，第一印象就崩了。
