HTML表单多行输入控件高度限制的设置-html教程-PHP中文网

textarea 的 rows 属性仅作初始渲染提示，非强制高度约束；当存在 height、max-height 或 min-height 等 css 时，rows 被忽略，应改用 min-height + max-height + overflow: auto 组合或动态监听 input 事件适配 scrollheight。

html表单多行输入控件高度限制的设置

textarea 的 rows 属性为什么设了却没用

因为 rows 只是初始渲染提示，不是强制高度约束。一旦你写了 height: 100px、max-height 或甚至 min-height（在某些盒模型下），浏览器就优先按 CSS 计算高度，rows 被忽略。

常见错误现象：

写 rows="6"，但实际只显示 3 行
加了 height: 120px 后，粘贴大段文字时底部被截断，滚动条突然出现
移动端软键盘弹出后，textarea 被遮挡，且拉不到可视区

真正起效的前提是：去掉所有影响高度的 CSS，或改用更兼容的组合：

保留 rows="6"，同时只设 min-height: 96px（假设字号 14px、行高 1.5、上下 padding 各 6px → 每行 ≈ 21 + 12 = 33px，6 × 33 ≈ 198px；按需微调）
加上 resize: vertical，让用户可手动拉伸，避免“卡死”感
禁用 resize: none 时，务必配 max-height 防止无限拉高

用 CSS 硬设 height 的风险在哪

height 会让 textarea 完全脱离内容驱动逻辑，后果比看起来严重：

用户粘贴含换行符的文本后，第一屏外的内容不可见，且无滚动条（因 overflow 默认是 auto，但 height 固定后可能不触发）
不同字体、字号、padding 下，同一 height 值对应的实际行数浮动极大（比如思源黑体 vs Arial，14px 下行高差 2–3px）
移动端行高渲染差异更明显，iOS Safari 对 line-height 的解析常比 Chrome 保守

替代方案更稳妥：

Doc To HTML

使用 MinerU 文档处理引擎将 Word 文档（.doc、.docx）转换为保留结构和格式的干净 HTML。

下载

用 min-height + max-height + overflow: auto 组合，既保底线又控上限
若必须视觉固定（如表单字段对齐），优先控制父容器高度，而非 textarea 自身
避免 height: fit-content——它对 textarea 无效，浏览器根本不支持

JavaScript 动态适配高度时要注意什么

监听 input 事件重设 style.height 是目前最可靠的自适应方案，但容易踩坑：

必须先设 this.style.height = 'auto'，再读 this.scrollHeight，否则 scrollHeight 会卡在旧值
不要用 keyup 或 change——它们漏掉粘贴、拖拽、右键粘贴等操作
性能敏感场景要加防抖，300ms 是较平衡的阈值；但移动端输入法上屏延迟高，建议不低于 200ms
scrollHeight 包含 border 和 padding，若 CSS 里写了 box-sizing: border-box，需确认是否已统一计算方式

最小可用代码片段：

const textarea = document.querySelector('textarea');
textarea.addEventListener('input', () => {
  textarea.style.height = 'auto';
  textarea.style.height = textarea.scrollHeight + 'px';
});