Less中rem多端适配核心是动态基准值@root-font-size，需编译期变量+运行时JS注入；除法须用unit()剥离单位；px2rem函数应封装统一基准，避免参数化除数；JS须校正DPR与横竖屏，且注入时机须早于样式计算。
Less里用rem做多端适配，核心是动态基准值而非固定html字体大小
直接在html上写死font-size: 50px或用JS硬设，看似简单，实则无法响应设备DPR、横竖屏切换和缩放行为。Less本身不执行运行时逻辑，所以“自动换算”必须拆解为两层：编译期变量控制 + 运行时JS注入基准值。关键不是让Less算像素，而是让它接受一个可变的@root-font-size，所有rem值都基于它运算。
常见错误是把px值直接除以@root-font-size，却忽略单位残留——Less除法默认保留单位，32px / 16px结果是2px，不是纯数字2，导致2px * 1rem变成2pxrem报错。
- 用
unit()函数剥离单位：unit(32px / @root-font-size, 'rem') - 或先转数字再乘
1rem：(32px / @root-font-size) * 1rem（Less会自动合并单位） - 推荐封装成函数，避免重复写
unit()：
.px2rem(@px) {
@rem-value: unit(@px / @root-font-size, 'rem');
return: @rem-value;
}
// 使用
font-size: .px2rem(32px);
为什么@root-font-size必须是变量而不是常量
因为多端适配需要根据设备宽度、DPR甚至用户偏好动态调整。比如iPhone SE（375px宽）和iPad Pro（1024px宽）理应使用不同基准值，否则小屏字体会过大。Less编译时无法获取window.innerWidth，所以这个变量实际是“占位符”，由构建脚本或运行时JS注入真实值。
典型做法是在HTML头部插入一段内联CSS，用JS计算后覆盖Less生成的默认值：
立即学习“前端免费学习笔记（深入）”；
<style>
html { font-size: <script>document.write(16 * (window.innerWidth / 375));</script>px; }
</style>
此时Less里的@root-font-size: 16px只是开发时的fallback，真正生效的是JS重写的值。若漏掉这步，所有rem都会按16px算，多端适配就失效了。
- 开发环境建议用
@root-font-size: 37.5px（对应750px设计稿等比缩放），方便设计师给的px值直接除以10 - 构建时可通过Webpack DefinePlugin将
@root-font-size替换为环境变量，区分H5/小程序 - 注意：Less变量作用域是块级的，
@root-font-size需定义在全局或@import顶层
divisor参数在px2rem函数里到底要不要暴露
有些方案把除数做成函数参数，比如.px2rem(32px, 37.5)，看似灵活，实则破坏一致性。一旦某处用了37.5，另一处用了100，rem体系就崩了。真正的“多端适配”依赖统一基准，不是每个元素自己选除数。
更危险的是，这种写法容易让人误以为Less在运行时做计算，进而忽略JS注入基准值的必要性。实际项目中，应锁死@root-font-size，所有转换都基于它。
- 如果真需临时切换（如弹窗强制16px基准），用嵌套作用域重定义变量：
{ @root-font-size: 16px; width: .px2rem(32px); } - 避免在函数参数里传除数，它不该是调用方关心的事
- 检查编译后CSS：确认所有
rem值都是类似2rem、0.875rem的纯数值，没有px残留
移动端viewport设置与rem基准的隐性冲突
很多人设了viewport: width=device-width, initial-scale=1，又用JS动态改html字体大小，结果发现iPhone X上字体忽大忽小。这是因为initial-scale=1在高DPR设备上会让CSS像素和物理像素不一致，而JS读取的window.innerWidth是CSS像素，但设备可能已缩放。
解决方案不是禁用缩放，而是用devicePixelRatio校正：
const baseWidth = 375; const scale = window.screen.width / window.screen.availWidth; const fontSize = baseWidth / 375 * (window.devicePixelRatio || 1) * 16; document.documentElement.style.fontSize = fontSize + 'px';
Less本身不参与这步，但它生成的rem值必须假设JS已正确设置基准。若测试时发现尺寸偏差，优先查JS是否读错了innerWidth或没处理DPR，而不是改Less函数。
- 真机调试时，在Safari开发者工具里检查
html元素的font-size计算值，不是Less编译值 - 微信内置浏览器对
rem支持有延迟，首次渲染可能用默认16px，需触发重排 - 小程序里不能操作
html，需用WXSS配合rpx，Less仅用于H5部分
实际落地时，最易被忽略的是JS基准值注入时机——必须在任何样式计算前执行，且要监听resize和orientationchange。Less只负责把设计稿的px干净地转成rem，别让它背运行时的锅。
