field-sizing: content 在 textarea 上不生效，它不是标准 css 属性，所有主流浏览器均未实现；textarea 自适应高度必须依赖 js + scrollheight，并需处理 ios 输入法、box-sizing、min/max-height 等细节。
field-sizing: content 在 textarea 上不生效——它不是标准 CSS 属性，所有主流浏览器（Chrome、Firefox、Safari，截至 2026 年 6 月）均未实现该行为，写了等于白写。
field-sizing 不是合法 CSS 属性，别被误导
你看到的 field-sizing: content 示例，基本来自三类混淆：
• 把 Chrome 实验性支持的私有控件（如 <input type="number">）误推广到 textarea
• 把 UI 框架的 autoSize props 或 JS 库行为当成原生能力
• 引用早已废弃的草案（CSS Basic UI Module Level 4），该草案从未进入浏览器引擎实现阶段
验证很简单：getComputedStyle(document.querySelector('textarea')).fieldSizing 返回空字符串；MDN 和 CanIUse 查不到该属性；iOS Safari 下甚至会导致 textarea 高度塌缩为 0。
textarea 自适应必须靠 JS + scrollHeight
目前唯一跨浏览器、可上线的方案只有手动读写 scrollHeight，但细节决定成败：
• 必须先设 el.style.height = 'auto'，否则 scrollHeight 会沿用旧内联高度，计算失准
• scrollHeight 已包含 padding，但不含 border；若未设 box-sizing: border-box，后续叠加会导致高度偏大
• min-height 和 max-height 必须用 CSS 显式声明，否则空值时缩成一条线，长内容时撑爆页面
• 父容器不能有 overflow: hidden，否则截断滚动区域，scrollHeight 返回错误值
示例核心逻辑：
function resizeTextarea(el) {<br> el.style.height = 'auto';<br> const height = el.scrollHeight;<br> el.style.height = Math.max(<br> parseFloat(getComputedStyle(el).minHeight) || 0,<br> height<br> ) + 'px';<br>}
iOS Safari 上高度跳动的根本原因
即使 JS 逻辑写对，在 iOS 上仍大概率失效，关键不在代码本身，而在运行时环境：
• 中文输入法候选阶段触发 input 事件，但内容未上屏，scrollHeight 还没更新
• 键盘弹起时 visualViewport 尺寸突变，导致 scrollHeight 计算滞后一帧
• compositionstart/compositionend 未监听，无法区分“输入中”和“已确认”状态
解决办法：
• 用 requestAnimationFrame 包裹赋值，避免渲染帧错位
• 同时监听 input、compositionstart、compositionend 和 resize（键盘弹起会触发）
• 删空后显式回退到 min-height：判断 el.value.trim() === '' 时重置高度
input 和 select 根本不支持高度自适应
<input type="text"> 是单行控件，浏览器强制限制为一行，任何 CSS（包括 field-sizing、height: fit-content）都无法撑高；<select></select> 渲染由系统 UI 控制，宽度适配在 Safari 上极不稳定（width: fit-content 失效、white-space: nowrap 易溢出）。所谓“自适应”，实际是 JS 动态测量 + getBoundingClientRect().width 的权宜之计，开销大、光标易跳动，生产环境不推荐。
真正容易被忽略的点不是怎么写 JS，而是：空值初始化时 scrollHeight 可能小于预期（字体未加载完）、textarea 默认 box-sizing: content-box、移动端软键盘遮挡视口后 resize 事件触发时机不可靠——这些细节不处理，上线后就是“偶尔正常、多数抖动”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
