width生效，cols完全失效；cols仅在无css width或max-width时作为可访问性提示起作用，不参与样式计算，且无法响应字体、缩放等动态变化。
cols属性和width同时存在时，谁生效？
width会完全覆盖cols的宽度效果——cols只在没有CSS设置width或max-width时起作用。一旦你写了width: 100%或width: 300px，cols就只是个摆设，浏览器直接忽略它对水平尺寸的“建议”。
这不是bug，是规范行为：cols本质是HTML层面的可访问性提示（比如屏幕阅读器可能用它估算输入容量），不是样式控制指令。
- 常见错误现象：
<textarea cols="60" style="width: 200px;"></textarea>在 Chrome 和 Safari 中，始终显示 200px 宽，cols="60"对视觉毫无影响 - 移动端尤其明显：
cols="40"在小屏上可能撑出横向滚动条，但加了width: 100%后立刻收敛 - 如果想保留
cols语义价值（如表单校验、无障碍支持），可以继续写，但别指望它管宽度
为什么不能靠cols实现响应式宽度？
cols的计算依赖默认等宽字体（如monospace）和固定字符宽度，而真实页面中字体往往是"Segoe UI"、"PingFang SC"这类比例字体，同一个cols="50"在不同字体下实际像素宽度偏差可达 ±30%。
更麻烦的是：cols不响应视口缩放、系统字体大小调整、用户自定义样式表——这些在无障碍场景中很常见。
- 示例：用户把系统字号调大 150%，
cols="40"的 textarea 可能只显示 20 多个字符就换行，但width: 100%+font-size: 1.2rem仍能正确撑满容器 - 不要用
cols做布局依据，比如写min-width: calc(50ch)来“模拟cols”，ch单位在非等宽字体下也不可靠（Safari 对 sans-serif 的ch计算常偏小） - 真正需要“字符级宽度约束”时，用 JS 测量真实渲染宽度（
getBoundingClientRect()+ 字体采样），但 95% 的表单根本不需要这么重
如何安全地移除cols而不破坏功能？
直接删掉cols属性不会影响任何运行时行为——只要你的 CSS 已正确定义了width、box-sizing和padding。
唯一需要注意的是：某些老旧后端校验逻辑可能读取cols值做服务端字段长度提示（比如“最多填cols个字符”），但这属于业务逻辑耦合，不是前端责任。
- 删除前确认：
textarea是否有 JS 代码读取element.cols？搜索项目里有没有.cols或getAttribute('cols') - 替代方案：用
data-cols-hint="50"这类自定义属性保留语义，既不干扰样式，又可被 JS 或后端读取 - 如果你用的是表单生成库（如 Formik、React Hook Form），检查 schema 是否硬编码依赖
cols；现代库通常只认style或className
resize: horizontal 被禁用后，cols 还有意义吗？
没有。当 CSS 设置了resize: none或resize: vertical时，cols连最后一点“用户拖拽参考”的作用都消失了——用户根本无法水平拉伸，也就无所谓“初始列数”是否匹配预期。
此时cols只剩两个实际用途：一是辅助技术（AT）读取，二是极少数表单引擎用它推导默认宽度（但这种设计本身就不健壮）。
- 如果你的项目要求 WCAG 2.1 合规，保留
cols是合理的（它属于 ARIA 推荐的可访问性 hint），但必须配合正确的 CSS 尺寸控制 - 别为了“看起来像有 cols”而写
width: 50ch—— 它和cols="50"不等价，且在中文场景下误差更大 - 真正容易被忽略的点：即使删了
cols，也要确保box-sizing: border-box已启用，否则padding和border会让实际内容区比width小很多
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
