tailwind 默认用 rem 是为保障浏览器缩放、系统字体调整及高 dpi 屏幕下的视觉一致性；px 在这些场景下易导致文字溢出、间距错位、圆角失真，而 rem 能等比缩放，但需动态设置 html font-size 并避免与 px 混用。
Tailwind 默认用 rem 不是为了“更现代”或“更高级”，而是它在浏览器缩放、系统字体调整、高 DPI 屏幕下能保持整体视觉节奏一致；px 在这些场景下会立刻导致文字撑出容器、间距错位、圆角生硬——如果你的项目要支持真实用户的各种访问方式，rem 是更稳妥的起点。
为什么 rem 在 Ctrl + + 放大时不会割裂？
用户按 Ctrl + + 或在系统里把默认字号从 16px 改成 20px 时：
-
rem值全部等比放大：padding: 1rem、font-size: 1.2rem、border-radius: 0.5rem同步变大 -
px值完全不动：padding: 16px还是16px，但文字已变成20px，按钮内边距立刻显得过紧
典型现象：开启“强制放大文本”后按钮文字溢出；高 DPI 屏幕下 padding: 16px 看起来像 8px；设计稿标 1000px 宽，用 px 写死后在 iPad 上窄得离谱。
rem 不是自动响应式，必须动态设 html font-size
单纯写 font-size: 1.5rem ≠ 响应式。它只认当前 html 元素的 font-size 值。默认 16px 是历史遗留，不能依赖。
- 首次渲染前没设置
document.documentElement.style.fontSize，所有rem都按16px算，和px效果一样 - 必须监听
DOMContentLoaded和resize，否则横竖屏切换（尤其 iOS Safari）不触发resize，布局就卡死 - 推荐 JS 公式：
document.documentElement.style.fontSize = window.innerWidth / 375 * 16 + 'px'（以375px设计稿为基准） - 加防抖（如
100ms），避免频繁重排；别用window.devicePixelRatio直接乘——它只影响渲染精度，不改变布局逻辑
哪些地方必须用 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，就得从 html { font-size } 开始统一规划——字体、间距、容器宽高走 rem，边框、阴影、图标尺寸走 px，行高用无单位值（如 line-height: 1.5），而不是在每个属性上单独决策。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
