Tailwind 默认用 rem 是因它在浏览器缩放和无障碍场景下更可靠：rem 随系统字体等比缩放，px 则导致视觉割裂；动态调整 html font-size 可实现真正响应式；仅边框、阴影模糊度等固定精度场景宜用 px。
Tailwind 默认用 rem，不是为了“显得高级”，而是因为它的行为在响应式缩放和无障碍场景下更可靠——换掉它容易，但代价得提前想清楚。
为什么 rem 在浏览器缩放时不会“错位”
用户在系统设置里调大默认字体（比如从 16px 改成 20px），或在浏览器里按 Ctrl + 放大页面，rem 值会等比放大，所有 padding、margin、font-size、border-radius 都同步变化。而 px 是硬编码的固定像素，放大后只有文字变大，间距和圆角还卡在原尺寸，视觉上立刻出现割裂感。
常见错误现象：
- 用户开启“强制放大文本”后，按钮文字撑出容器
- 设计稿标了
padding: 16px，转成px后，高配显示器下按钮看起来“太紧”
这不是 bug，是 px 的固有行为。如果你的项目明确不支持系统级缩放（比如仅内网 Kiosk 设备），那可以换；否则，别动根单位。
rem 如何支撑真正的响应式布局
Tailwind 的 sm:、md: 等断点本身不改单位，改的是「何时生效」；真正让整个 UI 按比例缩放的，是动态改 html 的 font-size。例如：
html { font-size: clamp(14px, 2.5vw, 18px); }
这时 py-4（默认对应 1rem）会从 14px → 18px 自动过渡，不需要你为每个断点重写一遍间距值。
使用场景：
- 移动端横竖屏切换时保持视觉密度一致
- 同一套组件在桌面端和 iPad 上复用，靠根字号微调即可适配
- 配合
postcss-pxtorem做旧项目迁移时，rem 是唯一能反向映射的单位
无障碍测试中 rem 的不可替代性
WCAG 要求界面元素必须支持至少 200% 的文本缩放。很多团队只测了 font-size，漏掉了 height、line-height、gap —— 这些在 Tailwind 里全靠 rem 绑定根字号才真正联动。
容易踩的坑：
- 手动把
text-lg改成text-[18px]，结果缩放时文字变大但行高不变，文字重叠 - 用
h-12（默认3rem）做按钮高度，换成h-[48px]后，屏幕阅读器用户缩放时按钮被截断 - 依赖
viewport缩放做适配，但 iOS Safari 对initial-scale的处理不稳定，rem+js 动态根字号才是兜底方案
什么时候可以放心用 px？
不是所有地方都适合 rem。以下情况用 px 更合理，且 Tailwind 允许局部覆盖：
- 边框：
border类如border border-gray-200默认是1px固定值，改 rem 反而失真 - 阴影模糊度：
shadow-sm对应box-shadow: 0 1px 2px 0 rgb(...)，这里的2px是渲染精度需求，不是视觉比例 - 图标描边/刻度线：SVG 内联样式或
stroke-width必须用px才能对齐像素网格
注意：这些是“值固定”的原子属性，不是“需缩放”的布局属性。混用没问题，但别把 spacing 或 fontSize 主干配置全切到 px——那是拿便利性换掉可访问性底线。
最常被忽略的一点：rem 的可靠性不来自它“多好写”，而来自它把缩放控制权交还给用户和系统。Tailwind 没帮你做这个选择，但配置文件里删掉一行 rem，可能让某个视力障碍用户再也点不准你的按钮。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
