rem 能随系统设置和视口自动缩放，px 则固定不变；rem 保障浏览器缩放、无障碍及跨设备一致性，但需动态设置 html font-size，且 border、box-shadow 等需像素精度处必须用 px。
rem 不是“比 px 高级”，而是它能随用户系统设置和视口变化自动缩放，px 则完全锁死——如果你的项目要支持浏览器缩放、无障碍阅读或跨设备一致体验，rem 是更可靠的选择。
rem 为什么在浏览器缩放时不会视觉割裂
用户按 Ctrl + + 放大页面，或在系统里把默认字体从 16px 调到 20px 时：
-
rem值等比放大：所有padding、font-size、border-radius同步变大 -
px值纹丝不动：文字撑大了，但按钮内边距、圆角半径还卡在原尺寸，视觉立刻错位
典型现象包括：开启“强制放大文本”后按钮文字溢出容器；高 DPI 屏幕下 padding: 16px 看起来太紧；设计稿标 1000px 宽，用 px 写死后在 iPad 上显得过小。
rem 不会自动响应屏幕尺寸，必须动态设 html 的 font-size
单纯写 font-size: 1.5rem 并不等于响应式——如果 html 的 font-size 没变，那它就还是固定像素。
- 推荐 JS 动态公式：
document.documentElement.style.fontSize = window.innerWidth / 375 * 16 + 'px'（以 375px 设计稿为基准） - 必须监听
DOMContentLoaded和resize，否则首次渲染错乱 - 移动端补监听
orientationchange，iOS Safari 横竖屏切换不触发resize - 加防抖（如 100ms），避免频繁重排；别用
window.devicePixelRatio直接乘——它只影响渲染精度，不改变布局逻辑
哪些地方绝对不能用 rem，必须坚持 px
rem 适合控制整体节奏，但某些属性需要物理像素级精度，强行用 rem 反而失真：
-
border: 1px：高 DPI 下本应保持清晰，用0.0267rem既难读又易错 -
box-shadow的blur值：模糊程度依赖像素采样，rem 缩放会导致虚化异常 -
background-size中的图标 sprite 定位：需像素对齐，rem 会引入 sub-pixel 渲染偏差 - 所有涉及
transform: scale()或canvas像素操作的场景
真正麻烦的不是换单位，而是混用：比如 padding: 1rem + border: 1px + font-size: 1.2rem，三者缩放逻辑不一致，调试时边界会突然“跳变”。决定用 rem，就得从根字号开始统一规划，而不是局部替换。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
