contenteditable可实现自适应高度输入框，但需手动处理换行（enter插br而非div）、粘贴纯文本、white-space/overflow样式、ios光标定位等细节，否则易出现高度卡死、内容隐藏、光标消失等问题。

contenteditable 能做自适应高度输入框，但直接设 contenteditable="true" 不等于“开箱即用”——它默认行为更像一个富文本编辑器，不是纯文本输入框，不自动换行、不处理回车、光标跳转异常、复制粘贴失控，这些都得手动兜底。

为什么 contenteditable 输入框会撑不开或突然截断

常见现象：输入几行文字后，容器高度卡死、内容被隐藏、滚动条没出现、甚至光标消失。根本原因不是样式没写对，而是浏览器对 contenteditable 元素的默认渲染逻辑和普通表单元素完全不同。

HTML Extract

使用 MinerU 从 HTML 页面和文件中提取内容，将 HTML 转换为保持标题、列表、表格及文本层次结构的干净、结构化 Markdown。F...

下载

• white-space: normal 必须显式设置，否则连续空格/换行会被压缩，pre 或 pre-wrap 会导致无法自动折行
• min-height 和 max-height 要配合 overflow-y: auto，但不能只靠 height: auto —— 它在 contenteditable 上无效
• 避免设 line-height 为无单位数值（如 1.5），某些浏览器下会干扰行高计算，建议用 px 或 em
• 父容器若用了 display: flex 且未设 align-items: flex-start，可能把内容顶出可视区

怎么让回车 = 换行，而不是插入 <div> <p>原生 <code>contenteditable 按 Enter 默认插入 <div>（块级），导致高度突变、样式错乱、提交时多出冗余标签。这不是 bug，是规范行为。 <ul> <li>监听 <code>keydown 事件，捕获 Enter 键（event.key === 'Enter'），调用 event.preventDefault()

手动插入 <br>：用 document.execCommand('insertLineBreak', false, null)（兼容性尚可，Chrome/Firefox/Edge 支持）

更稳妥的做法是操作 Selection + Range：获取当前光标位置 → 创建 br 元素 → 插入 → 恢复光标到 br 后

务必禁用 shift+Enter 的默认行为（它本该插 <br>），否则用户会误触发两次换行

粘贴进来的 HTML 怎么只留纯文本

用户从 Word、微信、网页复制内容，contenteditable 会原样接收所有 style、span、font、甚至 script 标签——这不是安全漏洞，是浏览器按规范保留来源结构。

• 监听 paste 事件，调用 event.preventDefault()
• 用 event.clipboardData.getData('text/plain') 提取纯文本（最简方案，丢弃所有格式）
• 若需保留基础格式（如粗体、链接），用 DOMParser 解析 text/html，再递归遍历节点，只保留 strong、a、br 等白名单标签，移除所有 style 属性和内联样式
• 注意：Safari 对 clipboardData.getData('text/html') 支持不稳定，必须 fallback 到 text/plain

真正难的不是让框“看起来能自适应”，而是控制它在各种输入、粘贴、聚焦、失焦、缩放场景下的行为一致性。比如 iOS Safari 中，软键盘弹起时 viewport 变化会导致 scrollHeight 计算失效；又比如当内容清空后，innerHTML = '' 会让光标定位异常，得用 textContent = '' + 手动 focus + restore selection。这些细节不写进逻辑，上线后就会变成偶发性问题。