rem并非天然优于px，而是通过动态设置html font-size实现全局等比缩放；若未动态更新根字号，则rem与px效果相同；px在浏览器缩放、高dpr屏下易导致视觉割裂，而rem可保持布局节奏一致，但边框、阴影等需像素精度处必须用px。
rem 不是“比 px 更适合”，而是它提供了可集中控制的等比缩放能力——前提是 html 的 font-size 必须动态更新；否则写成 rem 和写成 px 效果完全一样。
rem 的缩放行为依赖 html 的 font-size，不是自动生效
浏览器只认当前 html 元素的 font-size 值：1rem 永远等于那个值。默认 16px 是历史遗留，不能依赖。
- 首次渲染前没设置
document.documentElement.style.fontSize，所有rem都按 16px 算，和px无异 -
resize事件里不更新，横竖屏切换后布局就卡死（尤其 iOS Safari 不触发resize，还得监听orientationchange） - 用
clamp(14px, 2.5vw, 18px)或媒体查询分段设font-size是可行的，但硬写死html { font-size: 62.5% }只为换算方便，没解决响应问题
px 在缩放 / 高 DPR 下会视觉割裂
用户调大系统字体、按 Ctrl + + 放大网页、或用高 DPR 屏幕时，px 值纹丝不动，但文字、图标等会变大，导致间距错位、文字溢出、按钮圆角显得生硬。
-
padding: 16px + font-size: 16px→ 用户放大到 125%，文字变成 20px，内边距还是 16px，视觉上立刻“挤” - 设计稿标 1000px 宽，全用
px写死 → iPad 上显示窄、小屏上撑满但字太小，得靠一堆媒体查询补救 -
rem在这种场景下同步放大：padding: 1rem、font-size: 1.2rem、border-radius: 0.5rem全部等比变化，界面节奏不崩
哪些地方必须坚持用 px，混用会出问题
不是所有地方都适合 rem。强行替换反而引入 sub-pixel 渲染偏差或逻辑断裂。
-
border: 1px边框在高 DPR 下本应物理清晰，用0.0267rem（对应 1px）既难读又易错 -
box-shadow: 0 2px 4px：模糊半径依赖像素采样，rem缩放会让虚化程度异常 -
background-position用于 sprite 图标：需像素对齐，rem会导致偏移抖动 -
transform: scale()或canvas绘图：底层操作基于设备像素，rem会干扰坐标精度
真正麻烦的是单位混用，不是选哪个单位
写 padding: 1rem 却配 border: 1px + font-size: 1.2rem，三者缩放逻辑不一致。根字号一调，边界突然“跳变”，调试时根本没法归因。
决定用 rem，就得从 html { font-size } 开始统一规划——字体、间距、容器宽高走 rem，边框、阴影、图标尺寸走 px，行高用无单位值（如 line-height: 1.5），而不是在每个属性上单独决策。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
