通过 textarea.value.split('\n').length 就能快速统计文本域中的换行行数，但要注意它返回的是“换行符数量 + 1”，因此空内容时结果也会是 1；如果要校验最多 N 行输入，建议结合 Math.min(N, count) 做限制处理，同时应先将不同系统下的换行符统一为 \n 后再进行 split。
textarea.value.split('\n').length 怎么用才更稳妥
最常见、最直接的写法，就是使用 textarea.value.split('\n').length 来获取 textarea 的行数。不过要明确一点：它统计的其实是“换行符数量 + 1”，并不完全等于用户肉眼看到的“显示行数”。例如，空的 textarea 结果会返回 1；如果文本末尾额外带了一个换行符，也可能会被多算一行。实际开发中，我们更关心的往往是当前输入内容有多少逻辑行，或者光标所在的是第几行，而不只是简单的分割结果。
- 如果只是统计「输入了多少行文本」（例如限制最多输入 5 行），直接用
textarea.value.split('\n').length基本够用，但建议配合Math.min(5, count)做上限截断 - 如果要获取和页面 UI 实际显示一致的行数（比如包含自动换行、容器宽度变化等情况），就必须借助 DOM 计算：可使用
getClientRects()，或在监听input后通过textarea.scrollHeight / parseInt(getComputedStyle(textarea).lineHeight)估算，不过后一种方式受字体、内边距等影响较大，通常会有 ±1 行误差 - 不要依赖
textarea.rows属性——它仅表示 HTML 中设置的初始可见行数，并不能代表用户当前实际输入了多少行
为什么 onchange 或 blur 中拿不到最新的 textarea 行数
在 Layui 中，如果 textarea 放在 layui-form 结构里，又没有手动绑定输入事件，那么 onchange 往往是延迟触发的，通常需要在失去焦点且内容发生变化后才会执行。所以用户按下回车时，文本行数其实已经变了，但事件可能还没有及时触发。
- 更推荐的做法是监听
input事件：textarea.addEventListener('input', () => { /* 获取当前行数 */ }) - 如果项目中使用了
form.render()或form.on('submit')，要记得在回调函数中重新读取textarea.value，不要直接依赖闭包中缓存的旧值 - 在移动端场景下，软键盘收起时不一定会触发
input，因此还应额外监听blur事件作为兜底方案
layui-form-text 容器中如何准确放置行数提示
很多开发者会把“当前行数提示”直接放进 layui-form-item 内部，结果在响应式布局下容易出现错位或被遮挡的问题。因为 Layui 默认并不会为 textarea 下方的提示内容预留空间，所以需要手动处理定位方式。
- HTML 结构上，建议在
layui-form-text的div外层再包一层容器，然后追加 - CSS 一般需要给外层包裹容器设置
position: relative，再给提示元素设置position: absolute; bottom: -20px; right: 0; - 不建议依靠
margin-bottom去强行撑开间距——因为 Layui 的表单校验提示可能会动态插入，容易导致页面布局跳动
后端要求“最多 10 行”时，前端校验最容易忽略什么
当用户粘贴内容时，文本里可能包含 \r\n（Windows）、\r（老 Mac）或 \n（Unix/Linux）等不同换行格式。虽然大多数浏览器会做一定处理，但如果你只是简单用正则 /\r\n/g 替换后再 split，就可能漏掉单独的 \r，或者在混合换行场景下统计不准确。
- 更安全的写法是：
textarea.value.replace(/\r\n/g, '\n').replace(/\r/g, '\n').split('\n').length - 更稳一些的方式是先统一换行符，再分割统计：
textarea.value.split(/[\r\n]+/).filter(Boolean).length（过滤空字符串，避免空行干扰） - 还要注意：如果用户通过 Shift+Enter 插入的是软换行（
），这类内容不会直接体现在value中，普通textarea前端很难准确识别，通常需要富文本编辑器配合处理
真正复杂的情况在于“视觉行数”和“文本逻辑行数”并不总是一致。比如中文字体、英文等宽字体、emoji 表情混排时，同一段内容可能在页面上显示为两行，但在 value 中仍然只有 1 个 \n。这类问题前端通常只能做近似提示；如果业务要求非常严格，就需要后端结合实际渲染规则进行更精确的校验。
