cols 和 rows 仅控制 textarea 的近似可见尺寸，受字体、字号等影响大，不能精确控制宽高；应优先用 CSS 的 width、min-height 等属性配合 resize 实现可靠布局。
cols 和 rows 属性只控制可见尺寸，不等于实际宽度高度
直接设 cols="50" 或 rows="10" 看起来能调大小，但它们只是基于字符宽度（cols）和行高（rows）的**近似估算值**，受字体、字号、浏览器默认样式影响极大。比如 cols="20" 在 font-family: "Courier New" 下可能刚好 20 个等宽字符，换成 "Segoe UI" 就可能只显示 16 个左右。
常见错误现象：
— 输入中文时 cols 明显“缩水”，一行塞不满预期字符数
— 改了 font-size 后 rows 行数变少或溢出
— 响应式布局里 cols/rows 完全失效，尺寸卡死
- 纯语义化场景（如表单校验提示、简单配置项）可保留
cols/rows作为基础 fallback - 需要精确控制尺寸时，必须用 CSS 的
width/height/min-height配合resize -
rows对textarea的初始渲染行数有影响，但不会限制用户拉伸；cols几乎不影响 layout flow，仅作参考
用 CSS 替代 cols/rows 控制真实尺寸
现代项目里，cols 和 rows 应视为“降级保底”手段，真正尺寸靠 CSS 管理。重点不是删掉它们，而是不让它们干扰视觉一致性。
典型做法：
— 移除 cols 和 rows 属性，或设为合理默认值（如 cols="30", rows="4"）供辅助技术读取
— 用 width 和 min-height（而非 height）保证可扩展性
— 加 resize: vertical 或 resize: none 明确用户能否拖拽
- 避免写
style="width: 100%; height: 120px;"—— 固定height会截断内容，且无法自适应行数变化 - 推荐组合：
width: 100%; min-height: 80px; max-height: 200px; resize: vertical; - 若需等宽字体对齐（如代码编辑器），加
font-family: monospace;再配合cols才有点意义
兼容旧浏览器时 cols/rows 怎么设才不太翻车
IE11 及更早版本不支持 resize、min-height 在 textarea 上可靠生效，这时 cols/rows 成为唯一可控变量。但不能乱设。
经验数值（非绝对，需实测）：
— cols="50" ≈ 视觉宽度约 300–400px（取决于默认字体）
— rows="3" ≈ 初始高度约 60–75px（含 padding 和 line-height）
- 不要设
cols="1000"这类夸张值，IE 下可能触发怪异换行或滚动条错位 - 如果用了自定义字体，必须在 CSS 中同步重置
font-size和line-height，否则rows完全失准 - 搭配
overflow: auto;能缓解 IE 下内容溢出不可见的问题
textarea 自适应内容高度的实用方案
用户输入变多时，靠手动拉或固定高度都不够友好。cols/rows 对此毫无帮助，必须 JS 配合 CSS。
核心逻辑：监听 input 事件 → 临时设 height: auto → 读取 scrollHeight → 设回该高度 → 防止无限增长（加 max-height 限制）
- 关键 CSS：
textarea { resize: none; min-height: 60px; max-height: 200px; } - JS 中别直接改
style.height后立刻读scrollHeight，要等重排完成（可用offsetHeight触发或requestAnimationFrame） - 移动端注意：iOS Safari 对
scrollHeight计算有时偏小，可加 2–4px 安全余量
复杂点在于光标位置、粘贴行为、Enter 键处理——这些都和 cols/rows 无关，但却是真实项目里最常被忽略的边界情况。
