推荐用无单位数值（如line-height: 1.5）而非line-height: 24px，因其作为字体大小倍数动态缩放，避免响应式或嵌套字号变化时行距失控、文字重叠或截断。

line-height 用无单位数值（如 1.5）设置比例是最可靠的方式；其他值类型在嵌套、响应式或字体变化时容易出错。

为什么推荐用 line-height: 1.5 而不是 line-height: 24px

固定像素值会锁死行高，脱离字体大小的动态关系：

• 当子元素 font-size 变为 12px，line-height: 24px 会让文字上下留白过多，视觉松散
• 当子元素 font-size 变为 20px，同一 24px 行高可能压住字母“g”“y”的下降部，造成截断
• 用户放大系统字体或启用强制缩放时，px 值不随字体变化，行距反而变紧甚至重叠
• 响应式中用 rem 或 clamp() 动态调字号时，px 行高完全失联

line-height: 1.5 和 line-height: 150% 看似一样，但继承逻辑不同

两者计算结果常相同，但传播方式有本质区别：

Wechat Article Html

将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。

下载

• line-height: 1.5 是纯缩放因子，子元素继承该数字，再结合自身 font-size 重新计算 → 安全、可预测
• line-height: 150% 是“父元素当前 font-size × 1.5”所得的绝对像素值，该像素值被子元素直接继承 → 子元素不会再次乘自己字号，易导致小字号文字行距过大、大字号文字行距过小
• 若父元素 font-size 由 calc(1rem + 0.25vw) 动态生成，150% 可能在计算早期就固化一个中间值，而 1.5 始终保持实时绑定

给 inline 元素设 line-height 为什么没反应

不是没生效，是它作用的对象不是你想象的那样：

• line-height 控制的是**行框（line box）高度**，不是单个 span 的上下边距
• 给 span 设 line-height: 2，若其父 p 已撑开足够高的行框，span 只是按 vertical-align: baseline 对齐其中，视觉上“不动”
• 真正影响内联元素垂直位置的是 vertical-align：想和文字居中对齐，用 vertical-align: middle；想让图标底部贴齐文字基线，用 vertical-align: text-bottom
• input、img 等替换元素不受 line-height 直接“撑高”，它只参与所在行框的布局分配

做多行省略（-webkit-line-clamp）时，line-height 必须精确匹配

最后一行被切半或省略号悬空，90% 是因为这三个值没对齐：

• line-height 必须是纯数字或统一单位（推荐 1.6 或 1.6em）
• max-height 必须严格等于 line-height × 行数，且单位一致：例如 line-height: 1.6em + max-height: 4.8em（3 行）
• 若混用单位（如 line-height: 1.6em 但 max-height: 48px），浏览器计算偏差会导致截断错位
• display: -webkit-box 和 -webkit-box-orient: vertical 缺一不可，否则 line-clamp 不触发

最易被忽略的一点：全局 body { line-height: 1.6 } 是起点，但所有标题、引用块、代码行等特殊语义元素都必须显式覆盖——靠继承默认值，在复杂排版中大概率失效。