rows="5"不等于5行真实高度，因其仅按默认字体行高粗略估算，忽略padding、border及font-size变化影响；cols="50"在中文中塞不满50字，因cols基于等宽字符单位，而汉字为比例字体且更宽，实际显示仅25–30字。
rows 和 cols 不是尺寸控制的可靠手段，它们只提供基于字符的粗略估算，实际渲染受字体、字号、浏览器默认样式影响极大。需要精确控制宽高时，必须用 CSS。
为什么 rows="5" 不等于 5 行真实高度
rows 指的是“可见行数”的近似值，计算依据是当前字体的行高（line-height）和默认字符高度，但不包含 padding、border 或 font-size 变化带来的偏移。比如设 rows="4"，在 font-size: 16px + line-height: 1.5 下可能渲染出约 96px 高；一旦改成 font-size: 18px，同样 rows="4" 就可能撑到 120px 甚至触发垂直滚动条。
常见错误现象：
- 用户改了全局 font-size 后，所有
textarea行数看起来“变矮”或“溢出” - 在 flex 或 grid 容器中，
rows对齐失效，上下间距错乱 - 辅助技术（如屏幕阅读器）会读取
rows值作为语义信息，但视觉上完全对不上
为什么 cols="50" 在中文里根本塞不满 50 个字
cols 的单位是“平均字符宽度”，这个“平均”默认按等宽字体（如 Courier）算，一个英文字符 ≈ 1 个单位。但中文字体基本是比例字体，且汉字本身比英文字母宽得多——cols="50" 在 font-family: "Microsoft YaHei" 下，往往只能显示 25～30 个汉字，还可能因字重、字号缩放进一步缩水。
使用场景差异明显：
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
- 纯英文/代码输入：cols 还有点参考价值（尤其配合
font-family: monospace） - 多语言混合或中文为主：cols 几乎不可信，视觉宽度浮动超过 ±30%
- 响应式布局中：
cols是固定数值，无法随容器缩放，直接导致移动端溢出或留白过大
用 CSS 替代 rows/cols 控制真实尺寸
现代项目中，rows 和 cols 应仅保留为语义 fallback（例如供辅助技术识别初始规模），真实尺寸交由 CSS 管理：
- 用
min-height代替rows：比如min-height: 80px更稳定，且允许内容增长时自动扩展 - 用
width或max-width代替cols：推荐width: 100%配合父容器约束 - 加
resize: vertical显式控制拖拽行为，避免用户误拉成超宽窄高形态 - 禁用固定
height：写height: 100px会导致内容截断，且失去自适应能力
典型安全组合：
textarea {
width: 100%;
min-height: 80px;
max-height: 200px;
resize: vertical;
font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif;
}
兼容旧浏览器时 rows/cols 怎么设才不太翻车
IE11 及更早版本不支持 resize 和 min-height 在 textarea 上稳定生效，此时 rows/cols 是唯一可用的尺寸锚点，但不能瞎填：
- 避免极端值：不要设
cols="1000"或rows="100"，IE 下可能触发怪异换行、滚动条错位甚至 layout 崩溃 - 经验参考值（需实测）：
cols="40"≈ 视觉宽度 320–380px；rows="3"≈ 初始高度 60–75px（含默认 padding） - 若必须兼顾可访问性与视觉一致性，可同时写：
<textarea rows="4" cols="50" style="width: 100%; min-height: 80px;"></textarea>，让新浏览器忽略rows/cols的 layout 影响
真正麻烦的不是怎么设，而是不同字体下 cols 的“字符数”含义完全不同——它从来就不是像素，也不是 em，只是一个浏览器自己猜的数。别把它当尺子用。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
