cols和rows是语义提示值，非像素单位，仅按默认等宽字体估算初始可见区域；真实尺寸必须由CSS（如width、min-height、resize）控制，二者仅作无障碍fallback。
cols 和 rows 不是 CSS，也不决定像素尺寸
它们只是浏览器估算初始可见区域的提示值，不是 width/height 那样的确定性样式。cols="40" 不等于 width: 40ch，也不等于 320px；rows="6" 不等于 height: 96px，更不保证能显示 6 行中文。真实渲染高度取决于当前字体、font-size、line-height、padding 和浏览器默认行高基线——Chrome 和 Firefox 对同一 rows="6" 的计算结果可能差出 1 行。
常见错误现象：
-
font-size: 18px后，rows="4"只显示 2 行完整文本，第三行被截断 - 换用
font-family: "PingFang SC"，cols="50"实际宽度缩水 30% - 在移动端缩放页面时，
cols值完全不响应，导致水平溢出或换行错乱
为什么不能靠 cols/rows 对齐其他元素
因为它们不参与 CSS layout flow：既不触发 BFC，也不响应 box-sizing 或 width: 100%。当你写 style="width: 100%; box-sizing: border-box"，cols 还在后台默默按“平均字符宽”占位，容易引发水平滚动条、父容器撑开、或与相邻 input 高度不一致。
实操建议：
- 若需与旁边
input高度对齐，统一用min-height: 40px+padding控制，别指望rows="2"能匹配 - 响应式布局中，
cols值必须配合媒体查询重设（但不如直接用width管控） - 使用
resize: vertical时，rows仅影响初始高度，拖拽后它就彻底失效了
现代项目里 cols/rows 的唯一合理用途
它们不是过时属性，而是为辅助技术（读屏器）和无 CSS 场景提供语义 fallback。W3C 明确要求表单控件应声明可访问的初始尺寸提示。
所以该怎么做：
- 始终保留
cols和rows，但设合理值：cols="30"（短反馈）、cols="50"（长评论）、rows="4"（非代码场景） - 避免
cols="1000"或rows="1"这类极端值——前者在 IE 中会触发异常换行，后者让读屏器误判为“单行输入” - JS 动态创建
textarea时，必须手动设置这两个属性，否则部分读屏器报 “size unknown” - 若用自定义字体，务必同步在 CSS 中重置
font-size和line-height，否则rows计算完全失准
真正控制高度的 CSS 组合怎么写
视觉高度由 CSS 主导，且要兼顾自适应与可访问性。固定 height 是最常见翻车点——内容一多就截断，用户还拉不了。
推荐写法：
-
width: 100%—— 拉满父容器，不依赖cols -
min-height: 80px—— 保证至少显示 4 行（按 16px 字号+20px 行高估算） -
max-height: 200px—— 防止无限撑高，超出后自动出现滚动条 -
resize: vertical—— 明确允许用户调整，禁用则写resize: none - 搭配
overflow: auto，避免内容溢出不可见（尤其在 IE11 中）
示例：
<textarea style="width: 100%; min-height: 80px; max-height: 200px; resize: vertical; overflow: auto;" cols="30" rows="4"></textarea>
复杂点在于：min-height 的数值得结合实际字体和行高实测，不能只套公式；而 cols/rows 的存在，恰恰是为了不让这个实测值成为无障碍链路上的断点。
