推荐使用无单位数值（如 line-height: 1.5）而非像素值，因其基于当前 font-size 计算、可继承且适配缩放；带单位值会固定基准，易导致响应式失衡、多行省略错位及表单对齐异常。
line-height 设置为数值 vs 像素值，效果完全不同
直接写 line-height: 24px 看似精确，实则破坏继承性：子元素若字号变大，行高不会随之放大，文字容易挤在一起。用无单位数值（如 line-height: 1.5）才是推荐做法——它基于当前元素的 font-size 计算，可随字号缩放。
常见错误现象：line-height: 20px 用在 h1 和 p 上，结果标题行距太松、正文却贴得过近；或者响应式换字号后，行高完全失衡。
- 纯数字（如
1.4）是乘数，安全、可继承、适配缩放 - 带单位值（
px/em/rem）会固定计算基准，慎用于通用文本容器 - 百分比（
140%）等价于无单位数值，但可读性略差，不常推荐
line-height 在内联元素里经常“失效”？其实是 vertical-align 在捣鬼
line-height 本身只作用于**行框（line box）的高度**，并不直接控制单个内联元素的上下留白。当你给 span 或 a 单独设 line-height，往往没变化——因为它的父块级元素（比如 p）已经撑开了行框，子元素只是在里面对齐。
真正影响内联元素垂直位置的是 vertical-align。默认值 baseline 会让文字底部对齐，导致视觉上“行距不够”。
立即学习“前端免费学习笔记（深入）”；
- 想让链接或图标在行中更“挺拔”，优先调
vertical-align: middle或text-bottom - 给
input或button设line-height时，注意它们是替换元素，line-height只影响行框，不改变控件自身高度 - 用
display: inline-block模拟行内布局时，line-height仍作用于父容器的行框，不是子块自身
多行文本溢出（ellipsis）配合 line-height 要小心行高截断
当用 text-overflow: ellipsis 实现单行省略时，line-height 影响不大；但做**多行省略**（如 WebKit 的 -webkit-line-clamp）时，line-height 直接决定容器总高。设错会导致最后一行被切掉一半，或省略号位置偏移。
例如：想显示 3 行，font-size: 14px，理想行高是 1.6 → 每行高约 22.4px，3 行就是 67.2px。若容器 height 写死成 66px，就可能压住省略号。
- 多行省略容器必须同时设
line-height、max-height（=line-height × 行数），且单位一致 - 避免用
em或rem算max-height，易受祖先字号干扰；用calc()更稳，比如max-height: calc(1.6em * 3) - Firefox 不支持
-webkit-line-clamp，需备选方案（如 JS 截断），此时line-height仍是 JS 计算行数的关键依据
line-height 在表单控件和字体混排时表现不稳定
不同字体的 ascent/descent 差异很大，同一 line-height 值下，中文字体（如思源黑体）和英文字体（如 Inter）实际行框内留白分布不同。表单里 input、textarea 默认使用系统字体栈，line-height 很难精准对齐。
典型问题：输入框文字“下沉”，和旁边标签不对齐；或 button 文字紧贴顶部。
- 对表单控件，优先用
padding控制垂直空间，而非依赖line-height - 混用中英文时，若强制统一
font-family，某些英文字体在中文环境里会拉高行框，建议用font-feature-settings: "liga" off或降级字体栈 - 调试时用浏览器开发者工具的“layout”面板，勾选“show line heights”，能直观看到每行的
line-box边界
行高不是越调越大越好，关键在匹配字号节奏和内容密度。最常被忽略的是：它不控制元素自身高度，只参与行框构建——一旦忘了这点，所有对齐和截断问题都会找上门。
