cols 不是像素单位，也不参与 CSS 宽度计算，仅按默认等宽字体估算约可显示的英文字符数，其值会被 width 等 CSS 规则覆盖，且在不同字体、浏览器下表现不一致，应以 CSS 控制实际宽度，但保留 cols 作为可访问性 fallback。
cols 属性不计算实际宽度，只提供字符数估算
直接说结论：cols 不是像素单位，也不参与 CSS 宽度计算，它只是告诉浏览器“按默认等宽字体（如 monospace）下，大约显示多少个英文字符的宽度”。浏览器据此估算一个初始渲染宽度，但这个值会被任何显式的 width、max-width 或 flex 等 CSS 规则立刻覆盖。
常见错误现象包括：
- 写了
cols="50"，但加了width: 100%后完全失效 - 在移动端 Safari 中
cols被忽略，textarea 撑不满容器 - 换用
font-family: "Microsoft YaHei"后，一行实际只能塞下约 25 个汉字，远少于cols="50"的语义预期
为什么 cols="50" 在不同字体下宽度差异很大
cols 的底层逻辑依赖浏览器对“一个字符宽度”的默认采样——通常是等宽字体中数字 0 的宽度（即 ch 单位），但这个采样不随你设置的 font-family 动态更新。也就是说：
- 即使你设了
font-family: sans-serif，cols="50"仍按monospace下的字符宽度估算 - 中文场景下，
cols="30"在思源黑体中可能对应 280px，在 Courier New 中却接近 420px - Safari 对非等宽字体的
ch计算本身就不一致，导致cols和50ch也常不匹配
想控制实际宽度，该用什么替代 cols
现代布局中，应放弃用 cols 控制宽度，改用 CSS 单位并做兼容处理：
立即学习“前端免费学习笔记（深入）”；
- 用
width: 100%或max-width: 600px主控宽度，配合box-sizing: border-box - 需要“模拟字符宽度感”时，可试
width: 50ch，但必须实测：在目标字体下用getBoundingClientRect()测一个"0"的真实宽度再反推 - 对表单可访问性有要求时，仍保留
cols="30"作为语义 fallback（供屏幕阅读器识别大致输入容量） - 禁用用户拖拽缩放时，加
resize: none；允许垂直拉伸时，用min-height+max-height限定范围
容易被忽略的细节：cols 的默认行为和兜底价值
很多人删掉 cols 觉得“反正没用”，其实它在两个地方仍有不可替代的作用：
- 无 CSS 加载或样式失效时，
cols是唯一能撑开基本可操作尺寸的 fallback - 某些辅助技术（如旧版 NVDA）会读取
cols值来提示用户“这个框大概能输多宽”，删掉后可能影响可访问性评分
所以推荐写法是：<textarea rows="4" cols="30"></textarea>，然后所有真实尺寸控制全交给 CSS —— cols 不是废属性，只是不该指望它算像素。
