rem是根字号缩放的唯一可控路径，因其仅依赖html{font-size}，改一个值所有rem属性等比响应；而em嵌套失控、px无法适配系统缩放或高dpi屏幕。
rem 本身不自动缩放，它只忠实地把 1rem 换算成当前 html 元素的 font-size 像素值；所谓“适合根字号缩放”，是因为它把所有尺寸的缩放控制权收归到一个地方——html { font-size }。
为什么 rem 是根字号缩放的唯一可控路径
em 会随父级 font-size 层层嵌套，三层以后就很难反推真实像素；px 完全锁死，用户放大网页或换高 DPI 屏时，文字撑大但 padding、border-radius 还卡在原尺寸，界面立刻错位。而 rem 只看根，改一个值，font-size: 1.2rem、margin: 0.5rem、width: 20rem 全部等比响应——不是它更“智能”，是它把缩放逻辑扁平化了。
常见错误现象包括：
- 写了满屏
rem，但html上没设font-size，首屏仍按默认 16px 渲染，布局错位 - 用
html { font-size: 62.5% }图方便心算，结果 macOS + Safari 下系统字体缩放一开就失准 - 横竖屏切换时 iOS Safari 不触发
resize，font-size没更新，页面突然“变小”或“撑爆”
动态设置 html 根字号的可靠写法
核心是让 document.documentElement.style.fontSize 与视口宽度形成可预测的映射关系，且必须覆盖首次渲染和后续变化。
- 在
DOMContentLoaded事件中执行一次，确保首屏不按 16px 渲染 - 监听
resize和orientationchange（尤其 iOS），并加 100ms 防抖，避免重排风暴 - 公式推荐用
window.innerWidth / 375 * 16 + 'px'（以 375px 设计稿为基准），比vw兼容性更好，也比硬写媒体查询更平滑 - 别碰
window.devicePixelRatio去乘，它影响的是渲染精度，不是布局逻辑
哪些地方必须坚持用 px，不能套 rem
不是所有属性都该参与缩放。强行统一反而破坏物理精度和设计意图：
-
border: 1px：高 DPI 下本应保持清晰线，写成0.0267rem难读易错，且模糊边框不符合预期 -
box-shadow: 0 2px 4px：模糊半径依赖像素采样，rem 缩放会让虚化程度异常 -
background-position用于 sprite 图标：需像素对齐，rem 会引入 sub-pixel 偏移 -
line-height必须用无单位值（如line-height: 1.5），否则根字号一调，行距就失衡
混用单位才是真坑，不是选单位的问题
真正让调试崩溃的，从来不是 rem 或 px 本身，而是同一组件里三者混用：padding: 1rem + border: 1px + font-size: 1.2rem。根字号一调，内边距和文字放大，边框不动，按钮瞬间“上浮”或“下沉”。
落地时最常被忽略的一点是：rem 的缩放节奏完全取决于你如何定义和更新 html { font-size }。它不感知屏幕、不响应系统设置、不理会横竖屏——你不动它，它就永远等于 16px。所谓“优雅”，就是从第一天起就明确：字体、间距、容器宽高走 rem，边框/阴影/图标定位/行高走 px 或无单位值，并在项目初期就固化这套规则。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
