line-height 应使用无单位数值以确保跨浏览器稳定继承和响应式排版，避免固定单位导致的错位与失效，配合媒体查询实现结构化响应及 flex 布局优化对齐。
line-height 用无单位数值才能跨浏览器稳定继承
不同浏览器对 line-height: normal 的实现差异明显：Chrome 常返回 ~1.15，Firefox 约 1.2，Safari 可能低至 1.08。一旦父元素设了 line-height: 20px 这类固定值，子元素字体变大时行高不会同比例放大，排版立刻错位。
真正可靠的解法是统一使用无单位数值：
-
line-height: 1.6—— 子元素会按自身font-size自动计算行高，继承链中不会断裂 - 避免混用
px和em：比如font-size: 16px; line-height: 1.5em实际等于24px，但若子元素font-size改为20px，1.5em仍按父级 16px 计算，结果还是 24px，失去响应性 - 全局重置建议：在
:root或body设line-height: 1.5，后续所有文本容器默认继承，无需重复声明
table 单元格行高被撑开？优先锁死 td 的 height + line-height
给 <tr> 设 <code>height 基本无效——Chrome 完全忽略，Firefox 行为不一致。实际生效的是 <td> 或 <code><th> 的组合控制。
<p>固定单行数据表格高度的实操要点：</p>
<ul>
<li>
<code>td { height: 44px; line-height: 44px; box-sizing: border-box; padding: 0; } —— 高度与行高严格相等，文本垂直居中
box-sizing: border-box，否则默认 content-box 下 padding 会额外撑高vertical-align: middle（它和 line-height 冲突），改用 display: flex; align-items: center 更稳妥line-height 失效，应改用 max-height + display: -webkit-box 截断，或直接切为 Flex 布局移动端小屏下 line-height 过大会挤占空间，需媒体查询微调
桌面端用 line-height: 1.7 很舒适，但手机竖屏时行距过大，导致段落总高度翻倍，用户要频繁滚动。这不是“调小就行”，而是需要结构化响应。
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
推荐断点策略：
- 手机（
max-width: 767px）：line-height: 1.4—— 紧凑但不压迫，适配小字号 - 平板（
768px–1023px）：line-height: 1.55—— 平衡可读性与空间效率 - 桌面（
min-width: 1024px）：line-height: 1.65—— 充分利用横向空间，提升扫读体验 - 关键细节：所有断点内，
line-height必须保持无单位，否则媒体查询切换时会因单位换算出错
图片+文字混合容器中，line-height 影响 vertical-align 对齐逻辑
当 <img> 和文字同行显示（如图文列表），line-height 直接决定基线位置。设 line-height: 0 看似能消除间隙，但会导致文字不可见；设 line-height: 1 又可能让图片底部悬空。
真实可用的对齐方案：
- 文字容器设
line-height: 1.2，图片设vertical-align: middle—— 利用默认基线偏移补偿 - 更可控的方式：父容器
display: flex; align-items: center，彻底绕过line-height的基线干扰 - 若必须用 inline 布局，
img { vertical-align: -0.125em }比top/middle/bottom更精准，该值来自常见字体 x-height 比例 - 注意：Safari 对
vertical-align的解析比 Chrome 更保守，测试时务必打开真机 Safari 调试
最易被忽略的是：line-height 的继承不是“复制值”，而是“复制计算逻辑”。父元素用 1.5，子元素换字体后行高自动重算；父元素用 24px，子元素再大也卡死在 24px。这个底层机制决定了所有跨浏览器、跨设备的微调是否真正落地。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
