contenteditable仅靠CSS无法真正自适应高度，因其不触发重排、浏览器换行标签不一致、空行和冗余标签干扰scrollHeight计算；推荐textarea占位法或补全输入/格式/输出三层逻辑。
直接用 contenteditable + CSS 自动撑高，只能做出“能打字”的容器，不是真正的富文本编辑器——它不处理粘贴污染、格式冲突、光标错位、回车语义混乱等问题。真要可用，必须补输入层、格式层、输出层三块拼图。
为什么 contenteditable 不能只靠 CSS 就自适应高度
很多人试过给 div[contenteditable] 加 min-height 和 height: auto，发现换行后高度没变、滚动条乱跳、移动端光标消失。这是因为：
-
contenteditable元素默认不触发重排（reflow）来响应内容变化，尤其在 Safari 和旧版 Android WebView 中 - 不同浏览器对
Enter键生成的标签完全不同：Chrome 插<div>，Firefox 插<p>，Safari 可能混用，导致scrollHeight计算失准 - 空行、
<br>、孤立<span>会让offsetHeight和scrollHeight差值扩大，单纯监听input事件无法稳定同步高度
怎么让高度真正自适应（且不影响编辑逻辑）
核心是“绕开渲染依赖，用 DOM 结构驱动高度”。推荐用 textarea 占位法，而非硬刚 contenteditable 的渲染行为：
- 把
textarea绝对定位覆盖在视觉容器上，样式（font-size、line-height、padding）与占位div完全一致 - 监听
textarea的input和keydown（捕获Enter），每次触发后重置textarea.style.height = 'auto'，再设为textarea.scrollHeight + 'px' - 关键细节：必须先清空
height再读scrollHeight，否则缓存值会滞后；还要减去上下padding，否则高度虚高 - 如果必须用
contenteditable（比如要支持图片/表格），则需额外监听compositionend和cut/paste，并在这些事件后强制el.offsetHeight触发重排
加粗/斜体等格式操作会破坏高度自适应吗
会，而且很隐蔽。当你用 document.execCommand('bold') 或 range.surroundContents() 包裹文字时，插入的 <strong> 或 <em> 可能带默认 margin 或继承 line-height，导致行高突变。更麻烦的是：
立即学习“前端免费学习笔记（深入）”；
- 跨节点选区调用
surroundContents()会直接抛错，必须降级为extractContents()+ 逐段包裹，这个过程可能临时移除节点，引发高度抖动 - 用户粘贴 Word 内容后，一堆嵌套
<span style="font-weight:700">会撑开行高，但scrollHeight不反映真实视觉高度 - 解决办法：所有格式操作后，主动触发一次
textarea（或占位div）的offsetHeight读取，强制浏览器重排；导出前统一用CSSOM清洗内联样式，避免冗余style干扰高度计算
真正难的不是让框变高，而是让“变高”这件事不干扰格式状态、不丢失光标位置、不放大粘贴污染。每加一个功能（比如图片上传、表格插入），都要重新验证高度同步链路是否断裂——这才是生产环境里最常被忽略的点。
