textarea 的 rows 属性仅控制显示行数，不限制实际输入行数；真要限制需用 JavaScript 监听 input 事件，通过 split('\n').length 实时校验并截断，同时后端必须二次校验。
textarea 用 rows 属性只控制显示行数，不限制实际输入行数
很多人以为设置 rows="5" 就能卡死用户最多输 5 行，结果发现粘贴 20 行文本照样进去，滚动条照出——rows 只是渲染高度参考值，跟输入校验完全无关。真要限制行数，得靠 JavaScript 拦截和校验。
监听 input 事件 + 换行符计数是最直接的限制方式
核心逻辑：把 textarea 的值按 \n 切开，看数组长度是否超过上限。注意 Windows 和 macOS 的换行符都统一为 \n（现代浏览器会自动标准化），不用额外处理 \r\n。
实操建议：
- 用
element.value.split('\n').length获取当前行数（注意：空 textarea 算 1 行） - 在
input事件里实时检查，超限时截断最后一行（比如value = value.substring(0, lastNewlineIndex)） - 别只靠
keydown—— 粘贴、拖入、右键粘贴都绕过它，input是唯一覆盖全场景的事件 - 配合
setSelectionRange把光标推回合法位置，避免卡在非法区域
用 maxlength 防不住换行，但可辅助控制总字符量
maxlength 限制的是 Unicode 字符总数，不是行数。一个换行符占 1 个字符，所以它对“行数”只有间接影响。比如设 maxlength="200"，用户仍可能输 50 行（每行 4 字符 + 换行符），但无法输 100 行。
立即学习“前端免费学习笔记（深入）”；
适用场景：
- 作为兜底策略，防止极端情况（如复制万行日志）压垮页面
- 和行数限制叠加使用：
maxLines=10且maxlength=1000，比单用一种更稳 - 注意：中文输入法下，未上屏的候选字不计入
value，所以maxlength不会误触发
服务端必须二次校验，前端限制纯属体验优化
所有前端 JS 限制都能被禁用 DevTools、curl 或代理工具绕过。如果你的业务要求“绝对不能存超过 5 行”，那后端收到数据后，必须重新用相同逻辑（str.split('\n').length ）校验并拒绝非法请求。
容易被忽略的点：
- 数据库字段长度限制（如 MySQL
TEXT虽大，但业务逻辑可能要求单字段 ≤ 5 行） - 换行符标准化：入库前统一转成
\n，避免不同平台混杂导致行数计算偏差 - API 返回错误时，明确告诉前端是 “行数超限”，而不是笼统的 “参数错误”
