calc()中rem与vw不可混用，因单位基准不同；应统一为px+vw或仅用单一单位，并配合媒体查询、viewport标签、line-height固定及IE降级处理。
calc() 里不能直接用 rem/vw 混合单位做字体计算
很多人写 font-size: calc(1rem + 1vw) 发现没效果，或者在某些浏览器里字体卡死不动——这不是 bug，是 CSS 规范明确限制：calc() 中参与加减的每个值必须是**同类型可计算单位**。1rem 是相对根字体的长度，1vw 是视口宽度百分比，二者底层基准不同，浏览器拒绝合并。
真正能跑通的是把它们都转成同一“量纲”，比如全用 px 做中间桥梁，但更稳妥的做法是只用 vw 或只用 rem，再配合媒体查询兜底：
-
font-size: calc(16px + 0.25vw)—— 基准用px，增量用vw，合法且兼容性好（Chrome 26+/Firefox 16+/Safari 6.1+） - 根元素
:root { font-size: calc(16px + 0.25vw); }，再让子元素用em或rem继承，避免在每个选择器里重复写calc() - 别忘了设最小/最大限制：
min-font-size: 16px; max-font-size: 24px;（注意：这俩不是标准属性，得用@media模拟）
viewport meta 标签缺失会导致 vw 行为异常
如果页面没加 <meta name="viewport" content="width=device-width, initial-scale=1">，iOS Safari 和部分 Android 浏览器会把 100vw 算成「虚拟视口宽度」（通常 980px 左右），而不是你看到的屏幕宽度。结果就是字体突然变巨或变小，而且缩放时完全不响应。
这不是 calc() 的问题，而是 vw 单位本身失去参照系。修复只需一行 HTML，但容易被忽略：
立即学习“前端免费学习笔记（深入）”；
- 确保
里有且仅有一个 viewport meta，且width=device-width不要拼错 - 不要写
user-scalable=no，否则 iOS 上双指缩放失效，vw值不会随缩放重算 - 测试时用真机 Safari 开启「显示开发者工具 → Toggle Responsive Design Mode」，比模拟器更准
font-size calc() 在 flex/grid 容器中可能触发重排抖动
当父容器用 display: flex 或 grid，子元素又用了 font-size: calc(...vw)，某些 Chrome 版本（如 115–119）会在窗口缓慢拖拽时出现文字跳动。根本原因是：字体大小变化 → 行高变化 → flex 项目尺寸重算 → 容器重排 → 字体再次微调，形成微循环。
这不是渲染 bug，而是流式计算的固有延迟。缓解方式很实际：
- 给文字容器加
line-height: 1.4;（固定值），切断字体变化对行高的连锁影响 - 避免在
flex: 1或grid-area内部直接套calc()字体；改用外层容器控制尺寸，内部用em缩放 - 如需极致平滑，用
transform: scale()替代字体缩放（但会模糊，慎用于正文）
IE11 及以下完全不支持 calc() 里的 vw 单位
IE11 支持 calc()，但只认 px、%、em 这类传统单位，遇到 1vw 直接丢弃整个声明。表现就是字体退回浏览器默认大小，毫无响应性。
如果你仍需兼容 IE11，别试图 polyfill vw，成本远高于收益。务实做法是分层降级：
- 先写 IE 友好的基础尺寸：
font-size: 16px; - 再用
@supports (font-size: calc(1rem))包一层现代写法，把vw逻辑放里面 - 或者用 JS 检测
'vw' in document.body.style，动态写style标签（但注意 FOUC 风险）
真正麻烦的不是写法，是设计系统里所有基于 vw 的间距、圆角、阴影都得同步降级——字体只是第一个暴露点。
