contenteditable="true" 必须直接加在目标元素上，需排除父级禁用、css锁定、shadow dom及iframe designmode干扰；避免与readonly/disabled混用；react/vue中需特殊处理聚焦与状态同步。
contenteditable 属性怎么加才真正生效
直接写 contenteditable="true" 不一定能让元素可编辑——浏览器会检查父级是否禁用、元素是否被 CSS 锁定、是否在 shadow DOM 里，甚至 iframe 的 document.designMode 状态也会干扰。
- 必须加在目标元素上，不能只靠父级设置（子元素不会继承）
- 避免和
readonly或disabled同时出现，后者对非表单元素无效，但容易让人误以为“已控制” - 如果元素是空的，首次点击可能不聚焦，建议初始化时插入一个
<br>
- 某些框架（如 React）需用
contentEditable（驼峰）作为 prop，且要配合dangerouslySetInnerHTML或手动管理 focus
为什么按回车没换行，或者光标乱跳
这是 contenteditable 最典型的副作用：默认行为由浏览器决定，不同内核处理 Enter、Backspace、粘贴逻辑差异极大。Chrome 插入 <div></div>，Firefox 偏爱 <br>，Safari 可能套两层 <p></p>。
- 统一换行行为：监听
keydown，对Enter调用event.preventDefault()，再用document.execCommand('insertHTML', false, '<br>')（注意：该 API 已废弃但目前仍最稳） - 避免嵌套结构爆炸：给容器设
white-space: pre-wrap和overflow-wrap: break-word，并用 CSS 清除默认的p、div外边距 - 光标丢失常见于动态更新 innerHTML，改用
textContent+ 手动恢复 selection，或用Range+SelectionAPI 保持位置
如何安全获取编辑后的内容（不是 innerHTML）
innerHTML 会带一堆浏览器自动插入的标签、class、style，甚至不可见字符；而 textContent 又丢掉了所有格式。真实需求往往是“带基础结构的纯内容”，比如把 <strong></strong> 留下，但过滤掉 <span style="color:red"></span>。
- 别直接存
innerHTML到后端，先过一遍清洗：用DOMParser解析，遍历节点，只保留语义化标签（strong、em、ul、li），删掉style、class、data-属性 - 需要富文本语义？考虑用
execCommand的formatBlock统一段落结构，避免用户手敲<h2></h2>导致解析混乱 - 移动端长按复制/粘贴常触发意外格式，可在
paste事件里用event.clipboardData.getData('text/plain')强制转纯文本再插入
React/Vue 里 contenteditable 的坑比想象中多
框架的虚拟 DOM 和原生编辑行为天然冲突：React 不会响应 input 事件（因为不是表单控件），Vue 的 v-model 对 contenteditable 无作用，双向绑定得自己搞。
立即学习“前端免费学习笔记（深入）”；
- React 中必须用
useRef拿到原生元素，用useEffect监听input或blur更新 state，且要注意setState触发重渲染后光标重置问题 - Vue 3 推荐用
v-node手动 patch，或封装成自定义指令，监听compositionend防止中文输入中断 - SSR 场景下服务端渲染的
contenteditable="true"到客户端会立刻变可编辑，但初始值为空，需用key强制重载或延迟挂载
最麻烦的其实是 undo/redo —— 浏览器原生栈在框架更新后经常失效，真要支持，得自己实现命令模式快照，而不是依赖 document.execCommand('undo')。
