如何让HTML中的textarea自适应长文本高度？

本文共计938个文字，预计阅读时间需要4分钟。

使用 `scrollHeight` 和动态设置 `style.height` 是最可靠的实现方法，但必须配合 `style.height='auto' 重新设置，否则高度只增不减、光标跳动、移动端卡顿等问题都可能出现。

为什么 scrollHeight 是唯一靠谱的依据

scrollHeight 返回的是内容完整渲染所需的最小像素高度（含不可见部分），它不依赖字体、缩放、换行符类型，也不受 rows 或 CSS height 干扰。而 offsetHeight 和 clientHeight 只反映当前渲染尺寸，一旦有滚动条或溢出，它们就失效了。

• 空内容时 scrollHeight 至少等于 min-height（由 CSS 控制），不会塌成 0
• 粘贴大段文本后，scrollHeight 能立刻反映真实排版高度，比监听 change 或轮询更准
• 换行符差异（\r\n vs \n）在 IE11 中会导致 scrollHeight 偏小，但只需一行修复：textarea.value = textarea.value.replace(/\r\n/g, '\n')

input 事件里必须先设 height: auto

不重置高度就直接赋值 scrollHeight，浏览器会把旧 height 当作约束，导致计算失真——尤其在删减内容时，高度卡住不缩回，用户看到大片留白。

• 每次 input 触发时，第一句必须是：textarea.style.height = 'auto'
• 紧接着再读 textarea.scrollHeight，然后赋给 style.height
• 如果用了 box-sizing: border-box，scrollHeight 已包含 padding，无需额外加减；否则得手动减去 paddingTop + paddingBottom
• 移动端 iOS Safari 有渲染延迟，加 requestAnimationFrame 包一层比 setTimeout(..., 0) 更稳

别碰 contenteditable 模拟 textarea

除非你要做 @ 提及、实时语法高亮、富文本嵌入这类功能，否则纯文本输入场景下，contenteditable 是自找麻烦。

立即学习“前端免费学习笔记（深入）”；

• iOS 键盘收起后光标常消失，getSelection() 在 iframe 里失效
• 剪贴板行为不一致：右键粘贴和 Cmd+V 行为可能不同
• 空格、制表符、连续换行的解析逻辑和原生 textarea.value 不等价，后端接收时容易错乱
• 你省了高度计算，但要花三倍时间调光标定位、防 XSS、同步 undo 栈

移动端和老浏览器的硬坑

Mac 用户按 Cmd+Enter 插入 \n，Windows 默认是 \r\n，IE11 对后者计算不准——这不是 bug，是它没做换行归一化。如果你不能改后端（比如必须保留原始换行符），就只能经验补偿：

• IE11 下，textarea.scrollHeight + 2 是较安全的 fallback（仅限该浏览器）
• 禁用拖拽缩放：textarea { resize: none; }，IE11 不支持该声明，得靠 JS 拦截 mousedown on resize handle
• 初始 min-height 推荐设为 100px，太小（如 40px）在 iOS 上容易被键盘顶出视口

真正难的不是算高度，而是让每一次输入都“不打断用户”：光标不跳、不抖动、不闪、不卡帧。这些细节藏在重置顺序、RAF 调度、padding 归一化里，而不是某个神奇的 polyfill 里。