clamp(16px, 4vw, 32px) 是首选方案：16px为最小字号，4vw为动态基准，32px为最大字号，浏览器自动区间插值，兼顾响应性与可读性。
vw单位设置字体时为什么文字忽大忽小、布局错乱
直接用 font-size: 2.5vw 看似简单，但实际在小屏（如 iPhone SE）上可能缩到 10px 以下，导致可读性崩塌；大屏（如 4K 显示器）又可能撑到 60px+，破坏行高和容器约束。根本原因是 vw 基于视口宽度线性缩放，不设上下限就等于放弃控制权。
必须配合 min-font-size 和 max-font-size 逻辑——但 CSS 原生不支持这两个属性，得靠 clamp() 或媒体查询兜底：
-
clamp(16px, 4vw, 32px)是首选：第一个值是下限，第二个是动态基准，第三个是上限；浏览器会自动在区间内插值，比写多段@media更简洁 - 旧版 Safari（clamp()，需用
@media回退：比如先设font-size: 16px，再在768px、1200px两档手动调高 - 注意
vw是相对于整个视口宽度，不是父容器；如果文字在窄 sidebar 里，反而会比主内容区还大——此时该用em或rem配合根字体缩放
用媒体查询做响应式字体时断点怎么选才不踩坑
别按常见设备尺寸（如 320px、375px、414px）硬写断点。真实问题出在「文字是否换行」「行高是否挤压图标」「按钮文字是否溢出」——这些才是触发调整的信号。
推荐按内容表现设断点，而不是设备：
立即学习“前端免费学习笔记（深入）”；
- 用
min-width而非max-width，避免层叠冲突；例如@media (min-width: 48em)比@media (max-width: 767px)更易维护 - 断点值统一用
em（如48em），这样当用户放大系统字号时，断点也会同比例偏移，保持相对关系 - 字体大小变化建议阶梯式递进：比如
1rem → 1.125rem → 1.25rem，跳变太大（如1rem → 1.5rem）会让用户感知突兀
clamp() 和媒体查询混用时优先级和 fallback 怎么安排
clamp() 是声明式计算，媒体查询是条件覆盖，两者不冲突但有执行顺序：CSS 后写的规则会覆盖前面同名属性。所以 fallback 要写在 clamp() 上方，并用 @supports 隔离：
h1 {
font-size: 1.5rem; /* fallback for very old browsers */
}
@supports (font-size: clamp(1rem, 3vw, 2rem)) {
h1 {
font-size: clamp(1.25rem, 4vw, 2.5rem);
}
}这样既保底，又避免现代浏览器重复计算。注意 @supports 检测的是属性值语法支持，不是浏览器版本号。
- 不要把
clamp()和媒体查询对同一元素反复写多次——容易漏掉某条规则，造成字体忽闪 - 如果项目要兼容 IE，只能全量用媒体查询，因为 IE 不支持
clamp()且无@supports - 字体变化会触发布局重排（reflow），高频操作（如 resize）下建议加
will-change: font-size微优化，但仅限关键标题
字体响应式后 line-height 和 letter-spacing 怎么同步适配
只调 font-size 而忽略行高，小屏下文字会糊成一团；大屏下则显得松散空洞。行高不能写死 line-height: 1.2，它会随字体等比放大，但人眼需要的是「视觉行距稳定」。
- 用无单位数值（如
1.3）仍是安全选择：它基于当前font-size计算，语义清晰，兼容性好 - 若需更精细控制，对
line-height也套clamp()，例如line-height: clamp(1.2, 1.2 + 0.02vw, 1.5)，但需实测是否真有必要 -
letter-spacing建议保持normal或固定微调（如0.02em），避免用vw——字间距对可读性影响敏感，动态缩放反而易出错
真正难的不是怎么写，而是测试时得横跨 iOS/Android/桌面端缩放+系统字体大小设置+阅读模式开启等多种组合——漏掉任意一种，用户看到的就是不可读的乱码块。
