clamp()在小屏字体变小是因preferred值低于min而取min，需确保preferred≥min（如min=1.125rem、preferred=calc(1rem+0.8vw)），并同步校准line-height等属性，注意旧版Safari兼容性。
font-size: clamp() 为什么在小屏上反而更大？
直接套用 clamp(1rem, 4vw, 2rem) 很容易让 iPhone SE（375px）上字体变成 15px，低于设计要求的最小可读尺寸——这不是 bug，是 preferred 计算值低于 min 导致取了 min，但你设的 min 本身太小。
真正起效的前提是：确保 preferred 在典型小屏宽度下 ≥ min。例如：
-
min设为1.125rem（≈18px），比纯1rem更稳妥 -
preferred改用线性表达式，如calc(1rem + 0.8vw)，在 320px 时得 ≈23px，稳超min -
max别贪大，2.5rem（≈40px）已是多数标题的安全上限
width / padding / margin 能不能也用 clamp()？
能，而且比 font-size 更不容易翻车——因为不涉及继承链和行高耦合。但要注意单位混用的真实约束：
-
width: clamp(280px, 80%, 600px)合法：px 和 % 单位不可比，但浏览器会把 % 解析为当前容器宽的百分比，再与 px 比较数值大小（实际行为等价于max(280px, min(80%, 600px))） -
padding: clamp(0.75rem, 4vw, 2rem)安全：rem 和 vw 可混合，计算后统一转为像素比较 - 避免写
margin: clamp(1em, 5vh, 3rem)：em 会继承父级 font-size，而 vh 是视口单位，二者在不同上下文里数值基准不一致，结果不可控
line-height 和 letter-spacing 必须同步 clamp() 吗？
必须。因为 font-size: clamp() 只改字号，line-height: 1.5 这种无单位值虽会随 font-size 缩放，但缩放比例固定；而 line-height: 2rem 这种绝对单位会完全脱离字号变化，导致小屏文字挤成一团。
立即学习“前端免费学习笔记（深入）”；
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
推荐做法：
- 优先用无单位值：
line-height: 1.4—— 它自动按当前 font-size 缩放，最省心 - 若需精细控制（如标题行高需随字号非线性变化），则单独用
clamp()：line-height: clamp(1.2, 1.2 + 0.02vw, 1.6) -
letter-spacing同理，固定0.02em比0.1px更可靠，但若设计稿明确要求随宽度微调，就用clamp(0, 0.1vw, 0.2rem)
旧版 Safari 兼容性怎么处理才不掉坑？
iOS 13.4 之前的 WebKit 对 clamp() 有静默失效问题，尤其出现在两个场景：嵌套自定义属性、或写在 @media 块内部。降级不是加个 fallback 就完事。
实操要点：
- 禁止写
font-size: clamp(var(--min), var(--pref), var(--max))，改为硬编码或 JS 注入 - 降级声明必须独立成行，且放在 clamp 前：
font-size: 1.5rem; font-size: clamp(1.125rem, calc(1rem + 0.8vw), 2.25rem); - 不要在
@media (min-width: 768px)里套clamp()，它可能被整个忽略 - 真机测试不能只靠模拟器：iOS 13.3 实机上
clamp()在 flex item 内部偶尔计算延迟，建议加transform: translateZ(0)触发硬件加速
最常被跳过的细节是：clamp() 控制的是 font-size，但 line-height、padding、甚至 border-radius 的响应逻辑都得各自校准——它们不会因为你改了一个字号就自动适配。
