rem更适合控制字体层级和内边距比例，因其基于根元素font-size，可精准缩放并避免vw在软键盘弹出、横竖屏切换时的视口抖动问题，而border、阴影等应坚持用px。
rem更适合控制字体层级和内边距比例
当你需要保持文字大小、行高、padding之间的视觉比例关系时，rem是更可控的选择。它基于根元素的font-size，只要统一设置好基准（比如html { font-size: 100px }），所有rem值就按同一套缩放逻辑演算。
常见错误现象：vw写font-size: 4vw在小屏上可能算出11.2px，但iOS强制最小显示为12px，导致字号“卡住”不缩；而rem配合JS动态设根字号，可以精准落到12.5px、13.8px等中间值。
实操建议：
- 用
postcss-pxtorem把设计稿里的px转成rem，确保开发阶段写16px→ 编译后是0.16rem - 根字号计算推荐用
window.innerWidth / 375 * 100（以375px为基准），并加requestAnimationFrame节流 - 必须加
text-size-adjust: 100%防iOS系统字号干扰
vw在软键盘弹出时会意外重算，rem不受影响
在iOS Safari中，输入框聚焦、软键盘弹出会导致viewport高度收缩，100vw瞬间变小——如果你用vw控制一个弹层宽度，它可能突然“缩进”一半。而rem依赖的是你JS设置的固定根字号，只要不手动重设，就不会随视口抖动。
使用场景明确：涉及表单、搜索框、底部操作栏等交互密集区域，优先选rem做宽度或内边距，避免布局跳变。
实操建议：
- 不要用
vw设input的height或line-height，改用rem或px - 若已用
vw，需真机测试键盘弹起前后document.documentElement.clientWidth是否变化 - 安卓部分WebView对
vh更不稳定，但rem无此问题
border和阴影不能用rem，但也不能盲目用vw
rem用于border会导致缩放后边框粗细不一：小屏下0.02rem可能渲染成0.5px，浏览器强制向上取整为1px；大屏下又变成2px，失去一致性。而vw写border: 0.1vw看似合理，但0.1vw在375px宽屏幕下仅0.375px，多数浏览器仍渲染为1px，实际没生效。
正确做法是：边框、阴影、小图标一律用px，或用transform: scale()模拟细线（如border: 1px solid #000; transform: scaleY(0.5)）。
实操建议：
- 禁止在
border、box-shadow、border-radius里混用rem或vw - 如果设计稿要求
1px细线，直接写border: 1px，再用devicePixelRatio判断是否需要transform缩放 - 构建工具中可通过
postcss-px-to-viewport配置minPixelValue: 2，让1px不被转换
混用rem和vw时，基准必须对齐，否则padding会错位
有人把font-size用rem、width用vw，结果按钮文字缩放正常，但左右padding在某些屏幕下“卡住不动”。这不是单位本身的问题，而是两套缩放源头没对齐：JS设的根字号可能按375px基准，而vw天然按当前window.innerWidth算，一旦设备像素比、缩放、iframe嵌套介入，误差就暴露了。
性能影响不大，但视觉容差难控。真实项目里更稳妥的做法是：用vw控制全屏容器（.banner、min-height: 100vh），其余全部交由rem体系管理，并确保postcss-pxtorem的rootValue和JS里写的基准一致。
容易踩的坑：
- JS里写
fontSize = innerWidth / 375 * 100，但postcss-pxtorem配置rootValue: 37.5，结果CSS编译后数值对不上 - 横竖屏切换时只监听
resize，漏掉matchMedia('(orientation: landscape)')，导致根字号未更新 - 在
iframe里用vw，它的视口是iframe自身尺寸，不是顶层窗口
最易被忽略的一点：rem不是“自动适配”，它只是个乘法器；真正决定适配效果的是你JS怎么设根字号、设几次、依据什么条件设。很多问题表面看是单位选错，其实是动态设置逻辑没兜住边界情况。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
