rem根字号必须设上限以防平板撑爆布局，正确做法是用Math.min(clientWidth, maxWidth)限制最大适配宽度（如540px），确保iPad上font-size不超过72px。
rem 的根字号必须设上限，否则平板上会撑爆布局
直接按屏幕宽度等比缩放 html 字体大小，iPhone SE（375px）下 font-size 是 50px，iPad mini（768px）就变成 102px——按钮瞬间放大两倍，文字挤出容器。关键不是“要不要用 rem”，而是“怎么控它的放大边界”。
常见错误是只写 docEl.clientWidth / 750 * 100，没加限制。正确做法是明确最大适配宽度：
- 设
maxWidth = 540（对应 iPad 竖屏逻辑宽度的保守值），超出后固定根字号不再增长 - 用
Math.min(clientWidth, maxWidth)取小值再计算，保证 iPad 上font-size不超过 72px - 若项目需横屏支持，额外监听
orientationchange，横屏时按screen.height重新算（但仅限必要场景）
vw 不能直接套用设计稿换算，要避开 iOS 键盘缩放陷阱
html { font-size: 3.75vw; } 看似简洁，但在 iOS Safari 中唤起软键盘时，vw 会按“视觉视口”重算——视口高度骤减，font-size 跟着暴跌，导致文字突然变小、布局错乱。这不是 bug，是浏览器行为。
真机测试发现：安卓部分机型对小数 vw 渲染存在舍入误差，连续嵌套 rem 换算后偏差被放大。所以：
立即学习“前端免费学习笔记（深入）”；
- 纯
vw仅适用于字体、间距等容忍误差的场景，禁用于圆角、边框、高度等需严格比例的属性 - 若坚持用
vw做根字号，务必加 JS 补偿：window.addEventListener('focusin', () => { document.documentElement.style.fontSize = '...'; }) - 更稳妥的做法是：用
vw写容器宽度（如width: 90vw），用 rem 写字体和内边距，分工明确
平板适配必须混合 media query，单靠 rem/vw 无法处理结构断点
rem 和 vw 解决的是“等比缩放”，但平板和手机的交互逻辑不同：手机适合单列滚动，平板可能需要双栏、侧边导航、固定工具栏。这些不是尺寸问题，是布局结构问题。
例如一个商品列表页，在手机上每行 1 个，在 iPad 上应每行 2–3 个；一个弹窗在手机上占满全屏，在 iPad 上应限制最大宽度并居中。这时必须用媒体查询切结构：
- 断点别按物理像素设，用
min-width: 768px或min-width: 1024px这类逻辑宽度 - 优先用
@media (min-width: 768px) and (hover: hover)区分触屏/悬停设备，避免误判折叠屏 - 不要把所有样式都塞进 media query，只改 grid/column/flex-direction 等结构性属性，尺寸仍走 rem/vw
rem 和 vw 混用时，px 换算基准必须统一，否则组件会失真
很多团队用 postcss-pxtorem 把设计稿 px 转 rem，同时又在 CSS 里写 width: 50vw，结果发现按钮在某些机型上宽高比例失调。原因在于：rem 换算依赖 JS 动态设置的根字号，而 vw 是实时视口计算，两者基准不一致。
实操中必须守住一条线：
- 如果设计稿是 750px 宽，就定死
1rem = 100px（即 750 ÷ 7.5），JS 设置根字号时也严格按此公式 - vw 换算则统一用
100vw = 750px→1vw = 7.5px，那么 200px 就写26.666vw，而不是凭感觉写25vw - 所有 UI 组件库（如 Vant）内部若含 rem/vw 混用，必须确认其基准是否与项目一致，否则直接覆盖其样式
最易被忽略的是横竖屏切换时的基准漂移——clientWidth 在横屏瞬间可能取到错误值，建议在 resize 回调里加 setTimeout 延迟 100ms 再执行 setRem，给浏览器重排留出时间。
