rem本质是动态参照html根字体的相对单位，必须通过js或媒体查询主动设置html font-size才能实现等比缩放；若未设置则默认1rem=16px，与px无异。
因为 rem 能随系统字体设置、浏览器缩放和视口变化等比缩放，而 px 是绝对锁定的——但前提是必须动态控制 html 的 font-size；否则写成 1rem 和写成 16px 效果完全一样。
rem 不是自动响应式，它只认当前 html font-size 值
浏览器不会因为你用了 rem 就自动适配屏幕。它只做一件事：把 1rem 换算成当前 document.documentElement.style.fontSize 的像素值。
- 没手动设置过
font-size？那默认按 16px 算，1rem === 16px，和 px 没区别 -
DOMContentLoaded前没设好，首屏渲染就按 16px 计算，布局错位 - 横竖屏切换时 iOS Safari 不触发
resize，得额外监听orientationchange - 用
clamp()或媒体查询设html { font-size }可行，但硬写html { font-size: 62.5% }只为换算方便，不解决响应问题
px 在缩放/高 DPI 下会视觉割裂
用户调大系统字体、按 Ctrl + + 放大网页、或用 Retina 屏时，px 值纹丝不动，但文字、图标等会变大，导致界面错位。
-
padding: 16px+font-size: 16px→ 用户放大到 125%，文字变成 20px，内边距还是 16px，按钮立刻“挤” - 设计稿标 1000px 宽，全用
px写死 → iPad 上窄、小屏上撑满但字太小，得靠一堆媒体查询补救 -
padding: 1rem、font-size: 1.2rem、border-radius: 0.5rem全部等比变化，节奏不崩
哪些地方必须坚持用 px，不能硬套 rem
不是所有属性都适合 rem。强行替换会引入 sub-pixel 渲染偏差或逻辑断裂，调试时边界突然“跳变”。
-
border: 1px：高 DPI 下本应保持清晰线，用0.0267rem难读易错，且模糊边框不符合设计预期 -
box-shadow: 0 2px 4px：模糊半径依赖像素采样，rem 缩放会让虚化程度异常 -
background-position用于 sprite 图标：需像素对齐，rem 导致偏移抖动 -
transform: scale()或 canvas 绘图：底层操作基于设备像素，rem 会干扰坐标精度
混用单位才是真麻烦，不是选哪个单位的问题
真正拖慢开发的是单位混用带来的隐性耦合：比如 padding: 1rem 却配 border: 1px + font-size: 1.2rem，三者缩放逻辑不一致。
- 根字号一调，内边距放大、文字放大，但边框不动，组件瞬间“上浮”或“下沉”
-
line-height必须用无单位值（如line-height: 1.5），否则根字号调整后行距失衡 - 决定用 rem，就得从
html { font-size }开始统一规划：字体、间距、容器宽高走 rem，边框/阴影/图标尺寸走 px
最常被忽略的点是：单位选择不是孤立动作，而是整个样式体系的契约。改一个 font-size 就牵动全局，但前提是所有 rem 都基于同一参照系——否则不如不用。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
