contenteditable="true" 必须配 tabindex="0" 才能获得焦点和完整编辑能力；粘贴应优先用 text/plain 并过滤 HTML；回车需拦截并统一插入 <p>；空内容时插入 <p><br></p> 防塌陷。
contenteditable="true" 本身不卡，但没配 tabindex="0" 就等于没开开关
浏览器不会给 <div> 或 <p> 这类非表单元素自动加可聚焦能力。只写 contenteditable="true"，用户点鼠标能编辑，但键盘 Tab 切不过去、el.focus() 不生效、document.execCommand 全部静默——因为压根没焦点，Selection API 拿不到 range。
必须显式加上 tabindex="0"，这是所有后续交互（加粗、换行、粘贴拦截）的前提。漏掉这步，性能再好也白搭，连“启动”都失败。
-
tabindex="-1"只支持 JS 主动聚焦，无法进 Tab 链，不适合用户自主操作场景 - 某些旧版 Safari 对
tabindex缺失更敏感，光标点击后瞬间消失 - 若父容器有
overflow: hidden且内容溢出，tabindex="0"有时会触发滚动跳变，建议加scroll-behavior: smooth缓解
监听 paste 时用 event.clipboardData.getData('text/html') 是性能毒药
直接取 HTML 片段再塞进编辑区，等于把整个解析、渲染、样式计算流程重跑一遍。尤其粘贴 Word 内容时，常含几十层嵌套 <span>、style 属性、data-* 标记，DOM 操作耗时陡增，移动端容易卡顿甚至主线程阻塞。
真正轻量的做法是：优先走纯文本路径，再按需重建语义结构。
立即学习“前端免费学习笔记（深入）”；
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- 用
e.clipboardData.getData('text/plain')获取干净字符串，插入成本极低 - 若需保留段落/加粗等基础语义，先用
DOMPurify.sanitize(html, {ALLOWED_TAGS: ['b','i','u','p','br']})过滤，再插入——比全量解析快 3–5 倍 - 绝对避免
innerHTML = e.clipboardData.getData('text/html')，这是 XSS 和性能双坑
回车默认插 <div> 或 <p> 不是 bug，是跨浏览器不可控的 DOM 构建行为
Chrome 插 <div>，Safari 插 <p>，Firefox 两者都可能。这不是样式问题，而是浏览器在编辑流中自动生成块级容器的底层逻辑不同。放任不管会导致后端收到混杂结构，清洗成本远高于前端主动归一化。
拦截 + 手动插入看似多写几行，实则省掉大量服务端适配和 DOMDiff 计算。
- 监听
keydown，检测e.key === 'Enter'后e.preventDefault() - 用
document.getSelection()+range.insertNode(document.createElement('p'))统一插<p> - CSS 补
white-space: pre-wrap防止连续空格塌缩，避免额外空格处理逻辑
空内容时编辑区塌陷，是 layout 触发重排的隐蔽性能点
当用户全选删除后，<div contenteditable="true"></div> 高度归零，失去点击热区。下一次点击会触发 layout 计算 + focus 流程重走，视觉上表现为“点一下没反应，再点才聚焦”，实际是浏览器在补 height、line-height、padding 的重排过程。
解决方法不是加 min-height（那只是掩盖），而是让 DOM 始终保有一个可渲染的空节点。
- 监听
input或MutationObserver，检测到空内容时插入<p><br></p> - 不要用
<div><br></div>，<br>在块级容器里行为不稳定 - 这个
<p><br></p>节点要带data-placeholder="true"标记，方便后续读取时过滤掉
