contenteditable 是唯一无需 javascript 即可启用编辑的全局属性，但需避免空元素、user-select:none 等干扰；其 false/true/plaintext-only 取值影响粘贴行为；须显式设不可删子元素为 contenteditable="false" 并监听 beforeinput 防误删。
contenteditable 是唯一能直接让任意 HTML 元素变成可编辑区域的全局属性，不需要 JavaScript 初始化就能生效，但必须配合合理 DOM 结构和事件处理才能稳定可用。
为什么 contenteditable="true" 有时不响应点击？
常见错误是把 contenteditable 加在空元素或只含换行符的元素上，浏览器无法建立光标位置；另外，父级设置了 user-select: none 或 pointer-events: none 也会拦截交互。
- 确保元素有可渲染内容（哪怕是一个空格：
- 避免在祖先元素上设置
user-select: none，该 CSS 会阻止光标进入 - 不要用
display: contents包裹可编辑容器，它会让元素失去编辑上下文 - 移动端需额外加
autofocus或首次点击后手动element.focus()触发虚拟键盘
contenteditable 的三种取值行为差异
取值不是简单的布尔开关，false、true 和 plaintext-only 在不同浏览器中表现不一致，尤其涉及粘贴和格式保留。
-
contenteditable="false"：完全禁用编辑，但子元素仍可被单独设为true -
contenteditable="true"：默认富文本模式，粘贴 HTML 会保留样式和结构（如表格、列表），但可能引入不可控的style属性 -
contenteditable="plaintext-only"：仅 Chrome 和 Edge 支持；粘贴时自动 strip 所有格式，但输入时仍允许加粗/斜体等操作（取决于是否绑定execCommand）
如何防止用户误删关键结构节点？
当可编辑区域包含标题、按钮等语义化子元素时，用户拖选+Delete 可能直接删掉整个 <h2></h2> 或 <button></button>，破坏页面结构。
- 对不可删的子元素显式设置
contenteditable="false"，注意它会继承父级状态，所以必须显式覆盖 - 监听
beforeinput事件，检查inputType === 'deleteContentBackward'或'deleteContentForward'，再判断 selection 是否跨了保护节点 - 用
getSelection().anchorNode定位当前光标位置，避免依赖document.execCommand（已废弃）做防御 - 更稳妥的做法是限制编辑范围：只允许编辑
<p></p>、<span></span>等纯内容容器，把结构元素（如<header></header>、<aside></aside>）移出可编辑区域
真正难的不是开启编辑，而是控制编辑边界——什么时候允许格式、什么时候只许文字、哪些标签绝对不能动。这些细节不写进事件逻辑里，上线后就会在用户反复删改中暴露出来。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
