应使用无单位 line-height（如1.6）而非px值，因其基于当前字号动态计算、真正响应式；全局推荐 body{line-height:1.6}，标题可收紧至1.2但不低于1.15，段落间距用margin-bottom控制。
line-height 用无单位数值（如 1.6）而不是 px
直接写 line-height: 24px 看似简单，但一旦字体变大（比如用户放大字号、响应式切换到大屏、或子元素设了 font-size: 1.8rem），行高就卡死不动，文字立刻重叠或留白失控。无单位值才是真响应：line-height: 1.6 表示“当前元素的 font-size × 1.6”，子元素继承的是这个比例，不是固定像素。
常见错误现象：
— 按钮里文字被上下截断
— 移动端段落行距突然变窄，读起来费劲
— 中文标题加粗后，line-height: 1 导致字形挤压
- 正文起步推荐
line-height: 1.5～1.7（14–16px 字号下最稳） - 长段落或小字号（≤13px）可上探至
1.75，缓解视觉疲劳 - 标题类元素慎用
line-height: 1，哪怕字重够，也建议至少1.15防止基线粘连
别在 body 上设过低的全局 line-height
很多人图省事，在 body 里写 line-height: 1.2 或更小，结果所有子元素——包括按钮、导航项、标签——全被压扁。这不是“紧凑”，是破坏可读性与可访问性。WCAG 明确建议正文行高 ≥ 1.5，iOS/Android 触控最小高度也依赖它撑开空间。
容易踩的坑：
— button 继承了 body 的 line-height: 1.2，实际高度不足 40px，触控困难
— span 包裹数字或图标时，因继承过小行高，文字贴顶或下沉不居中
— 屏幕阅读器辅助技术依赖足够的行间留白来识别段落边界
- 安全起点：全局设
body { line-height: 1.6; } - 再针对性收紧：如
h1 { line-height: 1.2; }，但必须配合足够margin-bottom - 用浏览器 DevTools 的 “Computed” 面板检查真实生效值，别只看 Styles 面板
line-height 不等于段落间距，margin 才管段落之间
有人把 p 的 line-height 调到 2.5 来“拉开段落”，这会让单个段落内部行距爆炸，尤其三行以上时，视线从末行跳到下一段首行反而更吃力。行高管“行内呼吸”，段距靠 margin 控制。
典型混淆场景：
— 多列布局里，line-height 过大会让跨列阅读时找不到下一行起始点
— 深色背景+小字号下，仅靠增大 line-height 无法解决段落边界模糊问题
— 使用 CSS Grid/Flex 布局时，line-height 对容器整体高度影响有限，gap 或 margin 才是关键
- 推荐组合：
p { line-height: 1.6; margin-bottom: 1.5em; } -
em单位的margin会随字体缩放，和line-height形成节奏一致性 - 避免
margin-top+margin-bottom双设，用单侧margin-bottom防止嵌套时外边距合并（collapsing margin）
inline 元素调 line-height 看不见效果？先看它是不是独占一行
line-height 作用对象是「行框」（line box），不是单个 span。如果 span 前后都是文字、没换行、也没设置 display，那它只是行内流的一部分，调 line-height 只会影响整行高度，不会让这个 span 自身“变高”。
调试时的真实表现：
— 给 span 加 border: 1px solid red，发现高度没变
— 但给父 p 加同样 border，能看到整行被撑开
— 在 flex 容器里对 span 设 line-height，基本无效，因为对齐由 align-items 主导
- 想让某个
span独立控制高度：改display: inline-block或inline-flex - 需要垂直微调：配合
vertical-align: top/middle/bottom，比硬调line-height更可控 - 多行文本容器（如
div）里混排span和纯文本时，line-height仍生效，但需注意不同font-size下基线对齐可能错位
line-height 的解释差异——尤其是中文 Web Font 在 Windows Chrome 和 macOS Safari 下的基线偏移。上线前务必在真机上用系统默认字体跑一遍，别只信模拟器。
