rows属性仅控制textarea初始可见行数，非像素高度或最大输入行数；需配合cols使用，易受CSS干扰，推荐rows与min-height结合实现语义化与自适应。
rows 属性直接决定 <textarea> 初始可见行数，不是像素高度，也不是最大输入行数——它只管“一开始给你看几行”。设成 rows="3"，用户打开页面就看到约 3 行高，输入超出后自动出现滚动条。
为什么设了 rows 还是看起来很矮？
常见原因是没配 cols 或 CSS 干扰了默认渲染：
-
rows和cols是协同生效的：只设rows="5"但没设cols，某些浏览器（尤其旧版 Safari 或移动端 WebView）会按极窄宽度渲染，导致每行只能塞下几个字，视觉上“高但窄得看不见内容” - CSS 的
height或min-height会覆盖rows的计算结果；比如写了style="height: 20px;"，哪怕rows="10"也白搭 - 字体不一致时，
rows对应的实际像素高度浮动较大（比如等宽字体 vs sans-serif），别指望它精确到像素级
rows 和 CSS height 能不能一起用？
能，但要小心冲突：
- 如果只用
rows，浏览器按行高 × 行数估算高度，行高由当前字体、line-height等决定，不可控 - 如果只用
style.height，rows就完全失效，变成纯 CSS 控制——此时建议同时加resize: vertical，否则用户无法手动拉伸 - 推荐组合：
rows="4"+style="min-height: 80px; height: auto;"，既保留初始行数语义，又允许内容撑开（需 JS 配合 scrollHeight 实现真自适应）
动态改 rows 值时要注意什么？
JS 修改 textarea.rows 是即时生效的，但有隐性副作用：
立即学习“前端免费学习笔记（深入）”；
-
document.getElementById("t").rows = 8会重置整个尺寸计算，可能触发重排（reflow），频繁操作影响性能 - 在表单验证场景中，若用
rows表示“错误时展开”，记得同步处理cols，否则宽高比例突变显得突兀 - 服务端控件如 ASP.NET 的
HtmlTextArea.Rows属性，赋值后需确保未被后续 CSS!important规则覆盖，否则前端看不到变化 - 不要依赖
rows做响应式适配——它不随屏幕缩放变化，移动端请优先用媒体查询 +min-height
真正难的不是设几行，而是让高度既符合初始预期，又不卡住用户输入。多数项目里，rows 只该用作 fallback 或语义标记，实际高度控制交给 CSS 或 JS 更稳妥。
