cols属性仅表示以等宽字体为基准的可见列数，非像素宽度或字符上限，实际宽度受font-family、padding、border及父容器约束影响，中文显示效果不稳定，仅为语义提示而非精确布局工具。
cols 属性不是等宽字体控制开关
cols 属性根本不会触发等宽字体渲染，它只是告诉浏览器“我预期能塞下多少个平均字符宽度”。浏览器按当前 font-family 的实际度量去估算——哪怕你写了 cols="40"，而 font-family: "PingFang SC" 下一个中文字符占 16px，40 个字就约 640px 宽；换成 monospace，同样 cols="40" 可能刚好卡在 40 字符边界。但这个“卡”是巧合，不是控制。
常见错误现象：
- 设了
font-family: monospace就以为cols="50"能精准显示 50 个英文字符，结果因font-size或line-height拉伸导致换行提前 - 用
cols="30"+font-size: 14px在 Retina 屏上看起来窄了一半，因为像素密度影响字符渲染精度
想靠 cols 控制中文排版？基本无效
中文没有“字符宽度一致”的前提，cols 的估算模型基于西文等宽假设，对中文字体（如 "Microsoft YaHei"、"Noto Sans CJK"）完全失准。例如：cols="40" 在默认字号下，可能只容得下 22–28 个汉字（取决于字形、标点、全角/半角混排），且不同浏览器渲染差异可达 ±3 字。
实操建议：
- 放弃用
cols对齐中文输入长度，改用 CSSwidth+ch单位粗略模拟：比如width: 40ch比cols="40"更贴近等宽字体下的视觉宽度 - 若必须保留
cols（如满足可访问性要求），值应保守：中文场景下cols="30"对应视觉宽度约 320–380px，比写cols="50"更不易溢出 - 配合
white-space: pre-wrap和overflow-wrap: break-word防止长连续中文（如 URL、邮箱）撑破容器
cols 和 CSS width 同时存在时谁赢？
CSS 的 width 优先级永远高于 cols。只要写了 textarea { width: 100%; }，cols 就只起语义 fallback 作用——它不影响布局，但会被屏幕阅读器读出。
容易踩的坑：
- 在 Flex 容器里写
cols="50"，却没设min-width，结果textarea被压缩到 0 宽，cols彻底失效 - 用 JavaScript 动态改
textarea.cols = 60，但之前用 CSS 设了width: 400px，此时 DOM 属性更新不触发样式重算，视觉毫无变化 - 设了
box-sizing: border-box却忘了cols的估算不含 padding，实际内容区比预期窄 16px（默认上下 padding 各 2px，左右各 6px）
真正需要等宽排版时该怎么做？
如果目标是让用户输入时看到“每行严格对齐”，cols 不是解法，得靠组合手段：
- 强制使用等宽字体：
font-family: 'SFMono-Regular', Consolas, 'Liberation Mono', Menlo, monospace; - 用
ch单位设定宽度：width: 50ch;（注意：IE 不支持ch，需 fallback 到px） - 限制每行字符数靠 JS 监听
input事件 +element.value.split('\n').map(line => line.length)校验，而非依赖cols - 避免在响应式断点里动态改
cols值——它不响应 viewport 变化，CSSwidth+ 媒体查询才是正路
最常被忽略的一点：即使所有条件都满足，用户粘贴富文本（含不可见 Unicode 字符、ZWSP、零宽空格）仍会破坏等宽对齐，cols 对这类输入毫无约束力。
