用无单位数值（如1.6）设line-height最稳妥；px值会锁死高度导致多字号下留白或重叠，em/percentage继承逻辑不同，inline元素需配合vertical-align，多行省略须精确匹配line-height与max-height。
直接用 line-height 配无单位数值（如 1.6）是最稳妥、最可维护的解法；用 px 或 em 值容易在响应式或嵌套字体变化时导致行距崩塌、文字重叠或省略号错位。
为什么 line-height: 24px 在多字号场景下会失效
它把行高锁死在 24px，不管子元素字号是 12px 还是 28px，都强行撑开同一高度。结果就是：小字号文字上下大片留白，大字号文字挤成两行甚至重叠。
-
line-height: 24px在font-size: 12px的span里，行框高是 24px → 文字只占中间一小段，视觉松散 - 同一值用在
font-size: 20px的标题上，24px 行高几乎等于字号本身 → 行框太窄，descender（下降部）被截，字母“g”“y”底部被压 - 响应式中
font-size切换为rem时，px值完全不跟随缩放，用户放大字体后行距反而越来越紧
line-height: 1.5 和 line-height: 150% 有啥区别
表面效果一样，但继承行为不同：前者是纯乘数，后者是百分比，计算时机和传播逻辑有隐性差异。
-
line-height: 1.5是缩放因子，子元素继承该数值，再结合自身font-size重新计算行高 → 安全、可预测 -
line-height: 150%是“当前元素计算出的font-size× 1.5”，然后这个具体像素值被子元素继承 → 子元素不会重新计算，易造成继承失真 - 当父元素
font-size由em或calc()动态生成时，150%可能提前固化一个中间值，而1.5始终保持动态关联
给 inline 元素设 line-height 为啥没反应
不是没生效，是它作用的对象错了——line-height 控制的是**行框（line box）高度**，不是单个 span 或 a 的上下边距。
立即学习“前端免费学习笔记（深入）”；
- 给
span设line-height: 2，若其父p已经撑开足够高的行框，span只是在里面按vertical-align: baseline对齐，视觉上“没变” - 真正调整内联元素垂直位置的是
vertical-align：想让图标和文字居中对齐，用vertical-align: middle；想让链接底部对齐文字，用vertical-align: text-bottom - 表单控件如
input是替换元素，line-height不改变其自身高度，只影响它所在行框的排布，别指望靠它“撑高输入框”
做多行省略（-webkit-line-clamp）时 line-height 怎么配
它直接决定容器能否完整显示指定行数 + 省略号，算错一点，最后一行就被切掉半截或省略号悬空。
- 必须同时设置三个值：
line-height、max-height、display: -webkit-box等配套属性 -
max-height必须严格 =line-height × 行数，且单位一致：比如line-height: 1.6em，3 行就写max-height: calc(1.6em * 3)，别用48px这种固定值 - 避免用
em手动算max-height，一旦祖先元素改了font-size，整个高度就偏移；calc()是目前最稳的写法 - Firefox 不支持
-webkit-line-clamp，JS 截断方案仍需依赖line-height推算每行像素高度，所以这个值必须真实可靠，不能是估算
最容易被忽略的是：line-height 的值一旦写死在组件内部（比如某个 UI 库的 .card__text），就会绑架所有使用它的上下文；真正健壮的做法，是把它当作排版系统的「基线节奏」，统一定义在根或 typography 层级，而不是分散在每个局部样式里。
