clientHeight 返回元素内盒高度（含 padding，不含 border、margin），与行高无直接换算关系；其像素值需结合实际渲染行高（非 CSS line-height）和内容布局才能估算有效行数。
clientHeight 返回的是什么，和行高有什么关系
clientHeight 是元素内盒高度（不含 border、margin，含 padding），它反映的是当前滚动容器在视口中的像素高度，不是行数。想转成“有效行数”，必须知道每行内容在渲染后实际占多少像素——这取决于字体、字号、行高、padding、是否换行、是否含内联元素等。
常见误区是直接用 clientHeight / lineHeight 硬除，但：
-
lineHeight是 CSS 属性值，不一定等于真实渲染行高（尤其当内容含图片、vertical-align或不同 font-size 子元素时） - 编辑器里常有空行、缩进、代码块、内联代码标记等，导致视觉行高不一致
-
clientHeight包含 padding，而用户关心的“可视内容区域”通常要减去上下 padding
实操建议：先获取编辑器容器（如 contenteditable 元素或 textarea）的 clientHeight，再减去 getComputedStyle(el).paddingTop 和 paddingBottom，得到纯内容区高度。
如何可靠获取单行真实像素高度
靠 CSS line-height 推算容易失准，更稳的方式是现场测量：
立即学习“前端免费学习笔记（深入）”；
- 创建一个临时
span，样式与编辑器内文本完全一致（font-family、font-size、line-height、white-space 等） - 把一个典型字符（如
"x"）塞进去，append 到 body，读取其clientHeight - 或更贴近场景：在编辑器末尾插入一个带
position: absolute; visibility: hidden;的测试行，测其offsetHeight
注意点：
- 不要用
textarea的rows属性反推，它只对等宽字体+固定行高有效，且不响应 CSS 变化 - 若编辑器基于
div[contenteditable]，需确保测试行继承了所有计算样式（可用window.getComputedStyle(el, null)复制） - 遇到
pre或code块，行高可能由font-family: monospace和字符宽度共同影响，不能复用普通段落的行高
计算有效行数时必须排除哪些干扰
可视区域内“有效行”指实际显示文本内容的行，不是 DOM 节点数，也不是换行符数量。以下情况会拉高 clientHeight 但不增加有效行：
- 编辑器底部留白（光标在最后一行，但下面还有空白滚动空间）
- 某些富文本编辑器会在末尾自动加空
div或br占位 - 行内元素（如图标、emoji）撑高了某一行，但整行仍算作 1 行有效行 —— 此时不能按平均行高切分，得用
getClientRects()逐行测量
推荐做法：
- 对编辑器容器调用
el.getClientRects()，它返回每个文本片段的矩形数组，可过滤出 y 坐标落在scrollTop到scrollTop + clientHeight范围内的矩形 - 每个矩形对应一行（或一行中的一段），用
rect.bottom - rect.top算该行实际高度，再累加判断覆盖了多少“行单位” - 若只需粗略值，可取前 3–5 行的
offsetHeight平均值，比全局硬除更抗噪
textarea 场景下 clientHeight 行数估算的特殊处理
textarea 的 clientHeight 和行数关系最“透明”，但也最容易踩坑：
- 它的行高由
font-size × line-height主导，但若设了box-sizing: border-box，clientHeight就包含 border，必须先减掉 - 用户拖拽改变大小后，
clientHeight变化，但rows属性不变 —— 所以永远别信rows，只信clientHeight+ 实测行高 - 换行符
\n在textarea中总是触发新行，但若某行超长未换行，它仍占 1 行，只是横向溢出 —— 这不影响行数统计，但会影响你对“可视行”的理解
简单公式（仅限纯文本、无缩进、等宽字体场景）：
const style = getComputedStyle(textarea); const paddingY = parseFloat(style.paddingTop) + parseFloat(style.paddingBottom); const borderY = parseFloat(style.borderTopWidth) + parseFloat(style.borderBottomWidth); const contentHeight = textarea.clientHeight - paddingY - borderY; const lineHeightPx = parseFloat(style.lineHeight) || parseFloat(style.fontSize); const visibleLines = Math.floor(contentHeight / lineHeightPx);
但只要编辑器用了自定义字体、设置了 white-space: pre-wrap 或允许粘贴富文本，这个公式就失效 —— 必须回归到 getClientRects() 或逐行 DOM 测量。
真正难的不是算除法，而是定义清楚：你说的“有效行”到底指光标能停驻的位置数？还是有非空白字符的行数？还是浏览器 layout 后生成的行框（line box）数量？三者在复杂编辑器里经常不重合。
