应使用 screen.width / devicepixelratio 计算 rem 基准，而非 window.innerwidth；必须写全 viewport 标签；rem 仅用于尺寸类属性，line-height、border 等禁用；需监听 resize 和 orientationchange 并节流。
直接改 html 的 font-size，别碰媒体查询或 vw 做基准——前者覆盖不全，后者在键盘弹出、折叠屏、安卓 WebView 里容易失准。
为什么 window.innerWidth / 375 * 100 这种写法会翻车
它用的是视口宽度，但横竖屏切换时 window.innerWidth 可能滞后（尤其 iOS Safari），且含滚动条宽度；更关键的是，它没对齐设备逻辑像素。设计稿按 375px 宽出图，实际应以 window.screen.width / window.devicePixelRatio 算出 CSS 像素宽，再等比换算。
- 错误示例：
document.documentElement.style.fontSize = window.innerWidth / 375 * 100 + 'px'→ iPad 横屏时值突变，按钮文字撑破容器 - 正确做法：先取
screen.width，除以devicePixelRatio得真实 CSS 像素宽，再套公式（如 375px 设计稿）：screen.width / devicePixelRatio / 375 * 100 - 必须加节流：用
requestAnimationFrame包一层，避免 resize 高频触发导致页面闪动
viewport 标签写错，rem 全部失效
<meta name="viewport"> 不是可选项，是 rem 生效的前提。漏掉 maximum-scale=1.0 或写成 width=375，所有计算都基于错误视口。
- 必须写全：
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no"> - 禁止写
width=375—— 大屏手机会把整个页面压缩进 375px 宽度，内容挤成一团 - 别用 JS 动态改这个 meta —— 某些安卓 WebView 在 DOM 加载后修改 viewport 会忽略新值
哪些地方该用 rem，哪些必须用 px
rem 是缩放单位，只适合控制「尺寸类」属性；混进布局逻辑或渲染敏感项，会放大精度误差。
- 推荐用 rem：
font-size、width、height、padding、margin、border-radius - 禁用 rem：
line-height（用无单位数值，如1.5）、border（固定1px，小屏下0.02rem渲染不可见）、box-shadow偏移、transform: scale() - 第三方组件（如 Vant）可能重置
box-sizing，需额外加.van-button { box-sizing: border-box; }
初始化时机和监听不能只靠 DOMContentLoaded
DOMContentLoaded 触发时，某些安卓 WebView 还没完成 layout，clientWidth 可能为 0；横竖屏切换时仅监听 resize 不够，iOS Safari 的 orientationchange 事件更可靠。
- 首次设置建议放在
内联脚本中，避免 FOUC（内容闪动） - 必须监听两个事件：
resize和orientationchange，且用window.matchMedia('(orientation: landscape)')主动检测初始方向 - 第三方 SDK（如微信 JS-SDK）可能延迟注入，若依赖其接口获取屏幕信息，需加 fallback：超时 300ms 后用
screen.width回退
最易被忽略的点：rem 基准不是“越精细越好”，而是要和设计稿物理基准对齐；border: 1px 这种看似微小的固定值，在高 DPR 屏幕上其实已被设备自动增强，强行用 rem 去匹配反而破坏原生渲染一致性。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
