为什么直接改 font-size 不如改 CSS 变量
先说一个核心判断：直接在 :root 里写死 font-size: 16px，确实能控制 rem 基准。但一旦项目里涉及 padding、line-height、border-radius 这些属性，那就得每个地方手动改一遍——这显然不够聪明。而 CSS 变量呢？改一处，所有引用它的地方自动响应。
翻车现场很常见：定义了 --font-base: 16px，却忘了在 :root 里写 font-size: var(--font-base)。结果呢？1rem 仍然走浏览器默认的 16px，变量形同虚设。所以要注意三点：
- 变量必须带单位（
--font-base: 1rem或--font-base: 16px），不能只写数字 font-size: var(--font-base)必须显式写在:root规则里，否则不生效- 第三方组件若内部用
em计算padding，它不会随rem基准缩放——得额外覆盖
如何用媒体查询批量更新字号变量
别在每个断点里重复写 font-size。真正的做法是：统一在 :root 里定义变量，用媒体查询批量改值。这样一来，所有引用 var(--fs-h2) 的地方都会同步更新。
很多同学容易犯的错是——把变量定义在局部选择器里（比如 .card { --fs-h2: 1.5rem; }），然后在 @media 中试图修改 :root 下的同名变量。结果作用域不匹配，根本无效。
那么，正确的做法有哪些？
- 所有变量必须定义在
:root，确保全局可访问 - 媒体查询中只能通过
:root { --fs-h2: 1.75rem; }修改，不能写成.card { --fs-h2: ... } - 避免用
!important覆盖变量值，否则后续媒体查询无法再覆盖 - 断点之间不继承：如果桌面端没写
--fs-h2，它会回退到移动端初始值，不是“延续上一个断点”
clamp() 和 CSS 变量怎么配合才不出错
clamp() 本身支持变量，但前提是变量值必须是完整带单位的长度（比如 1.25rem），不能是纯数字加单位拼接。浏览器不会解析 calc(var(--a) * 1vw) 这类嵌套，也不接受 var(--fs-min) 是 1.125 这种缺单位的写法。
踩过坑的都知道，混用单位是翻车高发区：写 clamp(1rem, 4vw, 24px) 看似合理，但 1rem 和 24px 基准不同，小屏下可能因换算抖动。顺带一提，iOS Safari 对含 vh 的 clamp() 支持不稳定，优先用 vw 更稳。
--fs-h1-min: 1.125rem✔️，--fs-h1-min: 1.125❌（少单位）font-size: clamp(var(--fs-h1-min), var(--fs-h1-vw), var(--fs-h1-max))✔️font-size: clamp(1rem, calc(var(--fs-h1-vw) + 0.25rem), 2rem)✔️（calc()内变量必须自带单位）font-size: clamp(var(--fs-h1-min), 4vw, var(--fs-h1-max))❌（中间项没走变量，无法批量调控）
真机测试时最容易忽略的三个细节
开发时看着一切正常，上线后用户抱怨“字太小”，多半卡在这些地方：
iPhone 横屏时 vw 突然变大，导致 clamp() 冲到上限；部分安卓 WebView（比如微信内嵌页）禁用了 viewport 缩放，vw 计算失准；首次渲染时，旧版 Samsung Internet 可能回退到最小值。
所以，这几个检查项一定要过一遍：
- 务必检查
是否存在且生效 - 对窄区域（如侧边栏、弹窗按钮），别无脑套
4vw——先测真实容器宽度，再反推合理系数 - 加一句降级样式：
font-size: 1.25rem; font-size: clamp(...);，让不支持clamp()的浏览器有 fallback
很多时候，问题就出在路径依赖上——习惯了桌面调试，忽略了移动端的各种“惊喜”。
