rem是相对于根元素font-size的缩放单位，需动态设置html字体大小以实现响应式；vw在移动端存在软键盘导致的视口bug；rem与vw混用须统一基准，避免逻辑冲突；字体渲染差异要求预留视觉容差。
rem 是相对于根元素 font-size 的缩放单位，不是“自动适配”
很多人以为设个 html { font-size: 16px } 就万事大吉，结果在 iPhone 上文字小得看不清，在安卓平板上又撑满屏幕——rem 本身不感知设备，它只忠实地乘以当前 document.documentElement.style.fontSize。真正起作用的是你手动设置或动态计算的这个值。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 不要静态写死
html { font-size: 16px }，除非你明确放弃响应式字号 - 用 JS 动态设置根字体：根据设备宽度 / 设备像素比 / 用户系统字号偏好做加权，常见做法是
document.documentElement.style.fontSize = (window.innerWidth / 375 * 16) + 'px'（以 iPhone 6/7/8 宽度 375px 为基准） - 注意 iOS Safari 的
text-size-adjust: 100%必须显式关闭，否则系统缩放会干扰rem计算 - 使用
postcss-pxtorem转换时，确认其基准值（rootValue）和你的 JS 动态设置逻辑一致，否则 CSS 和 JS 对不上
vw 单位在移动端有不可忽视的视口 bug
vw 看似更“原生”，但实际在 iOS Safari 中，当软键盘弹出时，视口高度收缩，100vw 会瞬间变小，导致布局错乱；安卓部分 WebView 则对 vh 更不友好，100vh 常常小于可视区域。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 避免用
vw控制关键字号或容器宽高，尤其涉及输入框、弹层等交互密集区域 - 若必须用
vw（比如全屏 banner 字体），加一层兜底：例如font-size: clamp(14px, 4vw, 24px)，但注意clamp()在 iOS 13.4+ 才稳定支持 - 测试时真机必测：iOS 模拟器不会触发软键盘导致的视口重算，必须用真机连 Safari Web Inspector 观察
window.innerWidth和document.documentElement.clientWidth的实时变化
rem + vw 混用不是叠加增强，而是需要对齐基准
有人把 rem 用于字号、vw 用于间距，以为“双保险”，结果发现按钮文字随屏幕缩放，但边距却卡在某个断点不动——因为两套单位背后没有统一的缩放源头，它们各自参照不同逻辑演算。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 如果选
rem，就让所有可伸缩尺寸（字号、padding、border-radius、甚至 max-width）都走同一套根字体计算逻辑 - 如果选
vw，建议配合calc()补偿最小/最大限制，例如width: calc(80vw + 20px)防止过小屏下塌陷 - 混用场景仅推荐一种：用
vw设置根字体（html { font-size: 4vw }），再让所有其他尺寸用rem—— 这样本质还是单源驱动，vw只负责“播种”，rem负责“生长”
字体渲染差异会让 rem/vw 在不同系统上“看起来不一样”
同样的 16px 或 1rem，在 macOS 的 San Francisco、Windows 的 Segoe UI、Android 的 Roboto 下，字形宽度、行高、字重表现都不一致；更隐蔽的是，iOS 的字体抗锯齿策略会让小字号边缘发虚，而安卓可能显得更“硬”。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 别依赖绝对像素级对齐，用相对比例（如
line-height: 1.5）代替固定px行高 - 字号尽量避开 12–14px 区间，这个范围在高 DPR 屏幕上容易模糊，优先用
1.125rem（18px）、1.25rem（20px）等更鲁棒的值 - 用
font-smooth和-webkit-font-smoothing做微调，但注意它们只是 hint，不能替代设计层面的字号冗余
跨平台弹性真正的难点不在单位选择，而在你是否愿意为每种设备的字体渲染特性留出 1–2px 的视觉容差空间。
