Less中calc()响应式失效因编译器误解析，需用~"calc(100% - @{gutter}px)"转义输出；vw换算须分离单位，推荐.vw(@px)函数封装；媒体查询循环需确保断点条件完整且调用正确。
Less里用calc()做响应式宽度为什么总失效
因为Less编译时会把calc()当普通字符串处理，但如果你写成calc(100% - 20px)又容易被Less提前计算（比如把100% - 20px当成数学表达式报错）。关键不是“能不能用”，而是“怎么让Less原样输出calc()不碰它”。
- 必须用引号包裹整个
calc()表达式：width: ~"calc(100% - 20px)"; -
~""是Less的“转义输出”语法，告诉编译器：别解析，原样扔进CSS - 如果里面要拼变量，用插值
@{var}，但整个仍得包在~""里：width: ~"calc(100% - @{gutter}px)"; - 别用
calc(100% - @gutter)这种写法——Less会尝试算100% - 16，直接报错
用Less变量控制vw/vh单位换算时精度不准
比如想把设计稿的375px宽等比转成100vw，再按比例算其他尺寸，但直接写@base: 375; width: (@size / @base) * 100vw;会出问题——Less默认把vw当单位参与运算，结果变成0.26666666666666666vw这种无效值。
- 单位必须分离：先算系数，再手动拼单位字符串：
width: ~"@{ratio}vw";，其中@ratio是纯数字 - 更稳妥的做法是用函数封装：
.vw(@px) { width: ~"calc(@{px} / 375 * 100vw)"; }，调用.vw(75);输出width: calc(75 / 375 * 100vw); - 注意
calc()里的除法不能写成75px / 375，必须是75 / 375（去掉px），否则浏览器解析失败
媒体查询里用Less循环生成断点，但样式没生效
常见写法是.make-col(@n, @i: 1) when (@i =配合@media (max-width: @{bp})，但编译后CSS里断点数值对不上，或者媒体查询嵌套错乱。
- Less循环本身没问题，问题常出在变量作用域——
@bp在循环体外定义，所有迭代共用同一个值 - 必须把断点值作为参数传入：
.make-col(@n, @i: 1) when (@i = -
@breakpoints得是list类型：@breakpoints: 480px, 768px, 1024px;，不能是空格分隔的字符串 - 别在
@media里直接写~"(@{bp})"，Less不支持字符串拼接媒体查询条件
用Less函数动态算rem基准，但不同设备字体缩放后布局错位
很多人写@root-font-size: 16px * (100vw / 375); font-size: @root-font-size;想实现视口等比缩放，但实际在iOS Safari缩放文字时，1rem会跟着变，导致容器宽高比例失衡。
- 这种写法本质是hack，不是标准rem方案——它把
html的font-size强行绑定视口，但忽略了用户设置和系统行为 - 真正可控的方式是固定根字号（如
16px），用calc()在具体属性上做适配：padding: ~"calc(1rem + @{gutter}vw)"; - 如果真要动态根字号，必须用JS监听
resize重设document.documentElement.style.fontSize，Less只负责静态部分 - Less里
1rem永远等于编译时html的font-size值，它不会响应运行时变化
最麻烦的其实是calc()和Less变量混用时的引号层级、单位剥离、以及浏览器对嵌套calc()的支持差异——写完务必在目标浏览器里检查computed style，别只信编译输出。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
