field-sizing: content在textarea上完全无效，因它不是标准CSS属性，所有主流浏览器截至2026年9月均未实现；唯一可靠方案是JS监听input事件，结合scrollHeight动态设高，并须处理box-sizing、min/max-height及iOS输入法等细节。
field-sizing 不是标准 CSS 属性，所有主流浏览器（Chrome、Firefox、Safari，截至 2026 年 9 月）均不支持它用于 textarea 高度自适应——写了等于白写，且无报错提示。
为什么 field-sizing: content 在 textarea 上完全无效
你看到的“生效”案例，基本来自三类混淆：
- 把 Chrome 实验性支持的
field-sizing（仅限input[type="number"]等极少数控件）误推到textarea - 把 React 组件的
autoSizeprops 或 JS 库行为当成原生 CSS - 引用早已废弃的 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) {
el.style.height = 'auto';
const minHeight = parseFloat(getComputedStyle(el).minHeight) || 0;
el.style.height = Math.max(minHeight, el.scrollHeight) + 'px';
}
iOS Safari 是最大兼容性陷阱
即使 JS 写对了，iOS 上仍大概率失效，原因包括：
- 中文输入法候选字未上屏时，
input事件已触发，但scrollHeight还没更新，需监听compositionstart/compositionend - 键盘弹出时
visualViewport尺寸突变，导致scrollHeight计算失准，必须监听resize事件兜底重算 - 初始渲染时字体未加载完，
scrollHeight可能偏小，建议用requestAnimationFrame延迟读取 - 父容器设了
transform或overflow: hidden，会截断滚动计算范围，高度严重偏低
别被“现代浏览器支持”误导
所谓 “Chrome 127+ / Safari 17.4+ / Firefox 126+ 支持 field-sizing: content”，仅指部分场景下的宽度适配（如 select 或 input[type="text"]），且：
-
textarea的垂直方向自适应仍不被任何浏览器支持 - 即使宽度生效，
min-width和max-width也必须显式设置，否则空值时缩成光标宽 - 旧版 Safari（iOS 16.3 及更早）或 Android WebView 中，该声明直接被静默忽略
- 写上
field-sizing不会 fallback，而是彻底失效——没有渐进增强，只有全有或全无
真实项目里，最稳妥的做法仍是放弃“纯 CSS 自适应”，改用 min-height + max-height + resize: vertical，把控制权交还用户。JS 方案虽需处理细节，但可控、可测、可 debug。
