text仅支持单行输入，textarea支持多行换行；选错会导致回车无响应、内容截断或提交失败，且后端需区分处理换行符。
text 和 textarea 的核心区别就一条：前者只能输入单行，后者支持多行换行。选错会导致用户按回车没反应、内容被截断、甚至提交失败。
为什么 input[type="text"] 按回车不换行
这是它的设计行为，不是 bug。浏览器会把回车当作表单提交触发（尤其在 form 内），input 根本不解析换行符。即使加了 style="height: 100px"，它也只拉高容器，内部文本依然强制单行居中显示。
- 如果你需要用户输入地址、备注、反馈等含自然段落的内容，
input[type="text"]一定不合适 -
maxlength对两者都有效，但input的限制是“字符总数”，textarea还要额外注意换行符（\n）是否计入 - 服务端接收时，
textarea提交的值里会包含\n，而input不会——后端做长度校验或清洗逻辑时得区分处理
textarea 的 rows/cols 和 CSS width/height 怎么共存
rows 和 cols 是 HTML 原生属性，定义“可见行数”和“每行可见字符数”，仅作初始尺寸参考；width 和 height 是 CSS 控制的实际渲染大小。两者同时存在时，CSS 优先级更高，但 rows 会影响默认滚动行为（比如设 rows="2" 但 CSS 高度只够显示 1 行，就会出现滚动条）。
- 推荐只用 CSS 控制尺寸，删掉
rows/cols，避免语义与样式冲突 - 如果要禁用用户拖拽调整大小，加
resize: none；想只允许垂直拉伸，用resize: vertical -
wrap="off"可关闭自动折行（文本横向溢出），但不会影响换行符提交——用户仍可按 Enter 输入\n
移动端上 text 和 textarea 的软键盘行为差异
在 iOS 和 Android 上，input[type="text"] 默认唤起带「搜索」「前往」等 action 键的键盘，而 textarea 唤起的是带「换行」键的标准键盘。这个差异直接影响用户操作路径。
- 搜索框必须用
input[type="search"]（不是text），才能触发系统级搜索优化和键盘 action 键 - 如果误用
textarea做搜索输入，用户按「换行」会插入\n而非提交，体验断裂 - Android 上部分 WebView 对
textarea的maxlength支持不一致，建议 JS 层再做一次截断校验
真正容易被忽略的是：当后端接口文档写“字段类型 string”，开发常默认前端用 input，但实际业务要求支持换行（比如工单描述），这时候改组件不是加个属性的事——要同步检查 placeholder 渲染、label 关联、无障碍属性 aria-multiline、以及所有已存在的表单验证逻辑。
