<p>vw直接用于calc()导致字号失准，因未限定响应区间；应使用线性插值公式calc(14px + 6 * ((100vw - 320px) / 1600))，配合Less mixin封装、iOS横屏bug规避及~"..."转义防编译错误。</p>
calc()里用vw做字号为什么总不准
因为直接写 font-size: calc(16px + 0.5vw) 在小屏下可能比设计稿还大，大屏又增长过快——vw 是视口宽度的1%，而字号通常只需要在某个区间内线性变化，不是无脑随屏幕拉伸。
真正要的是“在320px到1920px之间，字号从14px平滑过渡到20px”，而不是让1920px设备显示 16px + 0.5 × 1920 = 112px 这种荒谬值。
- 先确定最小视口（如
320px）对应最小字号（如14px） - 再确定最大视口（如
1920px）对应最大字号（如20px） - 用线性插值公式：
calc(14px + (20 - 14) * ((100vw - 320px) / (1920 - 320))) - 注意分母必须是纯数字（不能带单位），所以
(1920 - 320)得手算成1600
Less里怎么封装成可复用的mixin
硬写一长串calc()既难读又难改，Less的.fontsize-viewport() mixin 能把逻辑收拢，还能默认兜底。
关键点在于：Less不能直接在calc()里做除法运算（浏览器解析时才计算），所以所有算术必须在Less编译期完成，只把最终系数传进去。
立即学习“前端免费学习笔记（深入）”；
- 定义mixin：
.fontsize-viewport(@min-vw: 320, @max-vw: 1920, @min-fs: 14px, @max-fs: 20px) { ... } - 内部用
@ratio: (@max-fs - @min-fs) / (@max-vw - @min-vw);算出每1px视口宽度对应的字号增量（单位是px/vw） - 生成样式：
font-size: calc(@min-fs + @ratio * (100vw - @min-vw)); - 务必加
font-size: @min-fs;作为不支持calc()或vw的降级
移动端iOS Safari对vw的兼容性陷阱
iOS 9.3+ 支持vw，但有个经典bug：横屏切换后，100vw 仍按竖屏宽度计算，导致字号突变。这不是Less或calc的问题，是浏览器渲染层没及时更新视口元信息。
真实影响场景：用户从竖屏点开一个弹窗，再横屏看——字体可能突然缩到极小，或撑破容器。
- 临时解法：监听
orientationchange事件，手动触发document.documentElement.style.fontSize = ''重绘 - 更稳做法：放弃纯
vw，改用clamp()（但iOS 13.4+才支持） - 如果必须兼容iOS 12，建议用
rem+ 媒体查询分段控制，vw仅作增强而非唯一方案
Less编译后calc表达式被转义或报错
Less默认会把calc(100vw - 320px)里的减号识别为Less运算符，导致编译失败或结果异常——比如输出成calc(100vw320px)。
根本原因是Less解析器优先尝试数学计算，而不是原样保留CSS函数。
- 用波浪号+引号包裹整个表达式：
font-size: ~"calc(100vw - 320px)"; - 或者把操作符前后加空格并用括号隔离：
font-size: calc(~"100vw" - ~"320px"); - 注意：~"..." 内部不能有变量插值，动态值必须拼进字符串，例如：
~"calc(@{min-fs} + (@{max-fs} - @{min-fs}) * ((100vw - @{min-vw}px) / @{range}))"
最易忽略的是：当用@range这种预计算变量时，它必须是纯数字（如1600），不能带px单位，否则字符串拼接后calc()语法非法。
