contenteditable="true"必须加在具体可编辑元素（如<div>、<p>）上，且需配合tabindex="0"确保聚焦；父级contenteditable="false"、CSS禁用user-select/pointer-events、Shadow DOM或iframe干扰均会导致失效。
contenteditable="true"加在哪才真正生效
直接写 contenteditable="true" 不等于马上能编辑——它必须加在你要编辑的**具体元素**上，比如 <div>、<p> 或 <span>，不能只设在父容器指望子元素继承。
常见失效原因：
- 父级写了
contenteditable="false"，子元素再设true也无效（“就近 false 优先”） - 元素被
display: none或visibility: hidden隐藏了 - CSS 里写了
pointer-events: none或user-select: none，光标点不进去 - 目标是
<input>或<textarea>，这些原生表单控件不支持该属性
推荐写法：<div contenteditable="true" tabindex="0">编辑我</div>。加上 tabindex="0" 确保键盘可聚焦，避免点击无响应。
为什么点了没反应？先查这三处
用户最常卡在这几个隐形拦截点：
立即学习“前端免费学习笔记（深入）”；
-
overflow: hidden且内容溢出时，焦点区域被裁切，看起来像“点不动” - JS 里监听了
mousedown或focus并调用了event.preventDefault()，中断了默认聚焦流程 - 元素在 Shadow DOM 内，或外层
iframe的document.designMode = "on"正在干扰
快速验证：临时删掉所有 CSS 和 JS，只留 <div contenteditable="true">test</div>，能编辑就说明是外围逻辑干扰。
如何安全获取编辑后的内容
innerHTML 会混入浏览器自动插入的 <div>、<p>、空标签甚至内联样式；textContent 又丢掉了所有格式。真实需求往往是“带基础语义的干净 HTML”。
- 若只需纯文本：用
element.textContent，最安全 - 若需保留
<strong>、<em>、<ul><li>等语义标签：先用DOMParser解析，再遍历节点白名单过滤 - 别直接把
innerHTML发给后端——至少过一遍el.innerHTML.replace(/]*>/g, '')去标签（注意：这会破坏结构，仅适合简单场景）
移动端粘贴 Word 内容时尤其危险，建议在 paste 事件中强制取 event.clipboardData.getData('text/plain')。
React/Vue 里 contenteditable 不是绑定个 prop 就完事
框架的虚拟 DOM 和原生编辑行为天然冲突：
- React 中要用
contentEditable（驼峰），不能用contenteditable；v-model在 Vue 里对它完全无效 - 输入不会触发
onChange或@input，得手动监听input、blur或用MutationObserver - 动态更新
innerHTML会导致光标丢失，恢复需用Range+SelectionAPI - 首次渲染为空时，Chrome 可能不聚焦，建议初始化插入一个 或
<br>
复杂编辑场景下，别硬套框架响应式逻辑——contenteditable 是原生能力，接管它就得按原生规则来，否则光标乱跳、回车异常、状态不同步会反复出现。
