<p>移动端line-height忽大忽小，因无单位值（如1.5）依赖font-size计算，而viewport缩放、rem动态字号及系统大字体模式会改变实际字号，导致行高异常；应改用calc(var(--lh-ratio) * 1em)实现平滑联动。</p>
line-height设为无单位数值时，为什么移动端文字行高忽大忽小？
因为无单位数值（如 line-height: 1.5）是相对于当前元素的 font-size 计算的，而移动端常通过 viewport 缩放、rem 动态字号或系统字体放大功能改变实际 font-size，导致行高被意外放大或压缩。
- 安卓微信内置浏览器在用户开启「大字体模式」后，
font-size可能翻倍，line-height: 1.5就直接变成原来的两倍行距，段落显得松散断裂 - iOS Safari 对
viewport的缩放处理更激进，配合text-size-adjust: auto（默认值），会二次干预行高渲染 - 用
px或em固定line-height（如line-height: 24px）看似稳定，但一旦字号响应式变化，行高就不再适配，小字号下显得拥挤，大字号下又留白过多
如何让line-height随字号平滑联动，又不破坏可读性？
核心是放弃绝对值，也不依赖浏览器默认缩放逻辑，改用 CSS 自定义属性 + calc() 显式建模字号与行高的比例关系。
- 定义基础比例：比如正文希望保持
font-size与line-height比值为 1.4～1.6，就设--lh-ratio: 1.5 - 在需要响应的元素上写：
line-height: calc(var(--lh-ratio) * 1em)—— 这里1em始终等于当前元素的font-size，乘出来就是动态行高 - 对超小字号（如
font-size: 12px）单独加兜底：@media (max-width: 375px) { body { --lh-ratio: 1.6; } }，避免行距过紧
body {
font-size: 16px;
--lh-ratio: 1.5;
line-height: calc(var(--lh-ratio) * 1em);
}
@media (max-width: 375px) {
body { font-size: 14px; --lh-ratio: 1.6; }
}line-height和font-size一起做媒体查询时，哪些断点最实用？
别按设备宽度硬切，按内容可读性切——重点盯住 375px、414px、480px 这三个主流窄屏临界点，再补一个 768px 平板横屏起点。
-
375px（iPhone SE / 8）：字号建议不小于14px，line-height比例调到1.6起，防止小屏挤字 -
414px（iPhone Pro Max）：可回落到1.5，但保留font-size: 15px避免视觉跳变 -
480px+：多数安卓中屏，可统一用1.4–1.45比例，更紧凑也更符合阅读节奏 - 千万别在
@media里只改font-size却漏掉line-height调整，这是移动端行距失控最常见的源头
使用rem或vw做字号响应时，line-height要不要也跟着变？
要，而且必须同步。用 rem 时，line-height 若写成 1.5rem 是错的——它会相对于根字号计算，而非当前元素字号；用 vw 更危险，line-height: 4vw 在不同宽度下可能完全失衡。
立即学习“前端免费学习笔记（深入）”；
- 正确做法：继续用
calc(var(--lh-ratio) * 1em)，1em天然跟随当前元素的font-size，不管这个字号是rem、vw还是clamp()算出来的 - 如果用了
clamp(14px, 4vw, 18px)设字号，line-height就必须用calc()动态匹配，不能写死 - 测试时重点看 iOS 微信：它对
vw渲染有延迟，line-height若没绑定1em，首次加载常显示为默认值，滚动后才重绘
实际调的时候，最容易被忽略的是系统级字体设置对 1em 的影响——它真会变，不是理论。所以别信“设了 ratio 就一劳永逸”，得在真机上开大字体模式连测三遍。
