rows属性仅控制textarea初始可见行数，非像素高度或最大输入行数；需配合cols使用，易受CSS干扰，推荐rows与min-height结合实现语义化与自适应。
textarea 的 rows 属性到底控制什么
rows 只控制初始可见行数，不是像素高度，也不限制用户能输多少行。设 rows="4"，页面加载时就给你留出约 4 行高的空间，内容超了就自动出滚动条——它不拦你输入，只管“一开始给你看几行”。
常见误解是把它当 CSS height 用，或者以为设了 rows="10" 就等于“最多输 10 行”。这两者完全无关：maxlength 控字符总数，rows 纯属视觉提示。
直接写 HTML 时怎么设 rows
在标签里写死最简单：
<textarea rows="5" cols="60"></textarea>
注意这几点：
-
cols必须配着用，否则某些浏览器（尤其旧版 Safari 或 WebView）会把宽度压到极窄，导致rows看起来“高但看不见字” - 默认值是
2，不写rows就按 2 行渲染 - 值必须是正整数，写
rows="0"或rows="-1"会被忽略，退回到默认 2 行 - 别写成
rows="5px"或rows="5em"—— 它只认纯数字
用 JavaScript 动态改 rows 为什么有时没反应
JS 修改 rows 属性本身没问题：
document.getElementById("myTextarea").rows = 8;
但容易失效的几个原因：
- CSS 的
height、min-height或max-height直接覆盖了rows的计算逻辑，比如写了style="height: 40px;"，rows就彻底失效 - 元素还没挂载到 DOM 就执行 JS（比如放在
<head>里又没加DOMContentLoaded），getElementById返回null - 用了框架（如 React/Vue），直接操作 DOM 属性可能被虚拟 DOM 覆盖，得用框架推荐的方式更新
rows 和 CSS 高度混用的坑
可以一起用，但得知道谁说了算：
- 只用
rows：浏览器按当前字体、line-height、padding推算高度，结果浮动大；换字体或改字号，高度就变 - 只用
style.height：rows彻底被无视，文本域变成固定像素高，且默认禁用拖拽（需手动加resize: vertical） - 推荐组合：
rows="4" style="min-height: 80px; height: auto;"—— 既保留语义（告诉辅助技术“这是约 4 行的输入区”），又允许内容撑开高度（配合 JS 读取scrollHeight可做真自适应）
真正难搞的是跨浏览器一致性：Chrome 和 Firefox 对 rows 的行高估算略有差异，移动端 WebView 更容易因缩放或字体 fallback 导致实际高度偏差一两像素。如果设计稿要求“必须精确到 1px”，那就别碰 rows，老实用 CSS。
