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