cols 和 rows 属性在响应式中基本失效，仅定义初始渲染尺寸，无法响应视口、字体或用户缩放；应改用 css 控制宽高、字体、行高及内边距，并避免固定 height 以适配软键盘弹出。
cols 和 rows 属性在响应式中基本失效
cols 和 rows 是 textarea 的 HTML 属性，它们只定义“字符宽度”和“行数”的**初始渲染尺寸**，背后依赖的是浏览器默认的等宽字体（如 monospace）和固定行高。一旦你用 CSS 设置了 width、height、font-size 或 line-height，这些属性就立刻失去控制力——它们不会随屏幕缩放自动调整，也不会响应字体变化。
常见错误现象：cols="40" 在手机上撑满全屏，在桌面端却只占半行；用户缩放页面后，rows="5" 实际只显示 3 行可见内容，但滚动条仍存在。
响应式 textarea 应该用 CSS 控制尺寸
把尺寸逻辑完全交给 CSS，才能真正响应视口、字体和用户偏好。核心是放弃 cols/rows 的尺寸职责，仅保留语义用途（如表单可访问性中的建议尺寸）。
- 用
width: 100%或max-width配合box-sizing: border-box控制水平空间 - 用
min-height+height: auto（配合resize: vertical）平衡初始高度与用户编辑需求 - 显式设置
font-size和line-height，避免因继承导致行高塌陷或溢出 - 对小屏幕加
padding: 0.5rem类似值，防止文字贴边
示例最小可用样式：
如果你了解HTML，CSS和JavaScript，您已经拥有所需的工具开发Android应用程序。本动手本书展示了如何使用这些开源web标准设计和建造，可适应任何Android设备的应用程序 - 无需使用Java。您将学习如何创建一个在您选择的平台的Android友好的网络应用程序，然后转换与自由PhoneGap框架到一个原生的Android应用程序。了解为什么设备无关的移动应用是未来的潮流，并开始构建应用程序，提供更
textarea {
width: 100%;
max-width: 600px;
min-height: 120px;
font-size: 1rem;
line-height: 1.5;
box-sizing: border-box;
padding: 0.75rem;
resize: vertical;
}
需要“模拟 cols/rows 行为”时的替代方案
如果你确实需要让 textarea 初始尺寸接近某个字符量（比如“显示约 50 字符宽、6 行高”），不能靠 cols，得按实际字体度量来估算：
- 用
ch单位近似字符宽度：width: 50ch（但注意：它依赖当前font-family是否支持等宽度量，且 Safari 对非等宽字体的ch计算不一致） - 用
em或rem搭配行高推算高度：min-height: calc(6 * 1.5em)（假设line-height: 1.5） - 更稳妥的做法：用 JS 动态测量（如
getBoundingClientRect()+ 字体采样），但仅在强需求场景下引入，多数表单不需要
注意：ch 不等于 cols ——cols="40" 假设每个字符占 1 个等宽单位，而 40ch 是基于当前字体中 “0” 字符的宽度，两者在非 monospace 字体下偏差可达 ±20%。
移动端软键盘弹出时的常见塌陷问题
iOS Safari 和部分安卓 WebView 中，软键盘弹出会触发视口缩放或 visualViewport 变化，导致 textarea 被顶出可视区，或 height: auto 失效后无法自适应内容增长。
- 避免给
textarea设固定height，坚持用min-height+height: auto - 监听
focus事件，必要时用scrollIntoView({ block: 'nearest' })手动修正位置 - 在 iOS 上，若父容器有
transform或fixed定位，可能干扰软键盘布局，需临时移除或改用position: absolute - 测试时务必真机验证，模拟器常无法复现软键盘导致的视口重排
最易被忽略的一点：很多团队以为只要写了 viewport meta 就万事大吉，但软键盘行为与 textarea 所在 DOM 层级、祖先元素的 overflow 和 contain 属性强相关，不逐层检查很难定位根因。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
