line-height 应用无单位数值（如1.5）而非像素，因其相对于当前 font-size 动态计算，确保响应式缩放时行距协调；clamp() 是目前最可控的字号响应方案，兼顾可访问性与阅读体验。
line-height 值为什么不能写成固定像素？
因为 line-height 设为像素（如 line-height: 24px）会锁死行高，当字号随屏幕缩放变化时，行距不会跟着变，极易出现文字挤在一起或空隙过大。响应式排版里，line-height 必须用无单位数值（如 1.5），它才是相对于当前 font-size 的倍数。
常见错误现象：在手机上字体变小后，行距没变窄，导致行与行之间空得离谱；或者在大屏上字体放大，但行高卡死，文字贴到一起。
- 始终用无单位值，例如
line-height: 1.4、line-height: 1.6 - 避免
line-height: 24px、line-height: 1.4em（em在嵌套中会累积计算，不可控） - 如果要微调某一段落，优先改
font-size或用margin-bottom控制段间距，别碰line-height的单位
字号响应式该用 rem 还是 clamp()？
clamp() 是目前最直接、可控的方案；rem 配合 JS 或媒体查询也能做，但多一层间接性，容易在 font-size 层级嵌套时失控。
使用场景：正文、标题、按钮文字都需要随视口平滑缩放，而不是“断点跳变”。
-
font-size: clamp(1rem, 4vw, 1.25rem)—— 最小 1rem，最大 1.25rem，中间按 4vw 线性过渡 - 注意
vw基准是视口宽度，竖屏手机上可能缩得太小，可加min-width保护或换用dvw（需检查兼容性） - 别在
html根元素上用font-size: calc(...)配合 rem，容易和用户系统字号设置冲突，影响可访问性
移动端文字太小看不清？别只调 font-size
单纯放大 font-size 可能让行宽失控，造成单行字数过少、阅读节奏断裂。真正影响可读性的，是「行长」+「字号」+「行高」三者的协同。
性能 / 兼容性影响：过度依赖 clamp() 在旧版 Safari（
- 限制最大行宽：
max-width: 65ch（ch是数字 0 的宽度，比px更语义化） - 搭配
line-height: 1.5—— 小字号时略高（1.6），大字号时略低（1.4），可用@media微调，但别频繁切换 - 检查实际设备上的渲染：iOS Safari 对
font-size小于 16px 的文本有强制放大行为，可能破坏布局，建议底线设为16px（或1rem且根字号 ≥16px）
line-height 和 font-size 响应式组合容易踩的坑
最常被忽略的是：字体加载完成前的 FOIT/FOUT 会让行高临时错乱，而 clamp() + line-height 组合在字体替换瞬间可能闪动。这不是 bug，是渲染机制决定的。
另一个隐形问题：某些中文字体（如 “思源黑体”）的默认 line-gap 较大，即使写了 line-height: 1.4，实际行高仍偏高，需用 font-optical-sizing: auto 或 text-rendering: optimizeLegibility 辅助（效果有限，优先选字体本身）。
- 不要对
line-height做媒体查询逐级覆盖，容易漏写、难维护；一套无单位值 +clamp()字号足够覆盖多数场景 - 避免在
body上设line-height后又在子元素里重置，尤其遇到display: flex或grid容器，行高可能被忽略 - 测试时打开系统「更大字体」和「粗体文本」辅助功能，很多所谓“响应式文字”在这里直接崩塌——那说明你用了绝对单位或没预留足够垂直空间
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
