不能只写 html { font-size: 13.3333vw; }，因为硬编码会丢失设计稿与基准的映射关系，换设计稿需手动改值、维护成本高；用 CSS 变量（--psd、--rfs）配合 calc() 可解耦并动态计算，但需注意 viewport 必须声明、calc() 精度陷阱及媒体查询兜底。
为什么不能只写 html { font-size: 13.3333vw; } 就完事？
这行 CSS 看似简洁，但直接硬编码 13.3333vw 会丢失设计稿与实际基准的映射关系。比如你按 750px 设计稿设了 100px 根字号，那 100 / 750 * 100vw = 13.3333vw 是对的；但如果换到 640px 设计稿，就得手动改成 15.625vw，维护成本高，还容易出错。
用 CSS 变量可以解耦：把设计稿宽度和目标根字号抽成可配置项，让计算逻辑留在 CSS 里，不依赖 JS 或构建时替换。
-
:root中定义--psd: 750（设计稿宽度）和--rfs: 100（期望的 1rem 对应 px 值） - 用
calc(100vw / var(--psd) * var(--rfs))算出动态font-size，浏览器实时解析 - 这样改设计稿宽度，只需调一个变量，全链路自动生效
- 注意：
calc()里不能混用单位（如var(--psd) + 'px'），必须全是数值或同单位
calc() 在 vw/rem 基准计算中有哪些精度陷阱？
CSS calc() 对小数的处理很“老实”——它不会四舍五入，也不会自动截断，但渲染引擎在最终像素映射时可能做舍入。比如 calc(100vw / 750 * 100) 在 390px 宽设备上算出来是 52vw，但 52 × 3.9 = 202.8px，而浏览器可能取整为 203px，嵌套多层 rem 后偏差会被放大。
- 安卓部分 WebView 对
calc()中小数运算有延迟，首次渲染可能用旧值，建议初始化后触发一次document.body.offsetHeight强制重排 - iOS Safari 在键盘弹出时会重算视口宽度，导致
100vw缩水，进而让calc()结果跳变——这不是 bug，是规范行为 - 避免在
calc()里做除法后再乘小数，比如calc(100vw * 0.133333)比calc(100vw / 750 * 100)更易失真，因为浮点误差不可控
怎样用媒体查询给 calc() 做安全兜底？
纯 calc() 不解决极端情况：小屏上 4vw 字体可能被 iOS 强制拉到 12px，大屏上又可能撑爆容器。这时候得靠媒体查询干预基准值本身，而不是等比例缩放之后再修。
立即学习“前端免费学习笔记（深入）”；
- 先用
@media (max-width: 375px)给小屏设最小font-size，比如html { font-size: 37.5px; } - 再用
@media (min-width: 750px)给大屏设最大限制，比如html { font-size: 75px; }，防止无限放大 - 这些媒体查询要写在
calc()规则之后，确保覆盖生效（CSS 层叠顺序） - 别用
min-font-size——目前只有 Safari 支持，且仅作用于font-size，不影响 padding、width 等其他 rem 计算
viewport meta 缺失时，calc(100vw / var(--psd) * var(--rfs)) 会算错什么？
没加 <meta name="viewport" content="width=device-width">，所有基于 vw 的计算都失效。浏览器默认用 980px 布局视口，此时 100vw = 980px，不是设备真实宽度。结果就是：你写的 calc(100vw / 750 * 100) 算出来是 130.67px，1rem ≈ 130.67px，整个页面 UI 被严重放大、横向溢出。
- 这个错误无法被 CSS 变量或
calc()修复，必须在 HTML<head>里硬写死 viewport meta - JS 动态注入 meta 标签无效——浏览器解析 HTML 时已确定布局视口，后期插入不生效
- 真机调试时发现元素尺寸异常、有横向滚动条，第一反应就该查 viewport 是否缺失或写错
真正难的不是写出那行 calc()，而是理解它背后依赖的视口模型、渲染时机和设备差异。变量只是语法糖，底层逻辑没理清，换种写法照样崩。
