必须用rem而非px的场景是需单点控制缩放，如适配系统字号调整、无障碍放大及主题切换——当用户将浏览器默认字号设为20px或24px时，仅rem能确保按钮文字与间距同步等比变化，而px完全失效。
HTML响应式模板里用相对单位，不是“选一个单位套进去就行”，而是得按场景分层决策：哪些地方必须用 rem，哪些地方只能靠 vw/vh，哪些地方用 % 反而会失效。关键不在单位本身，而在它依赖的上下文是否可控。
什么时候必须用 rem 而不是 px
rem 的核心价值是单点控制缩放，比如适配不同系统字号、无障碍放大、主题切换。如果你的模板要支持用户把浏览器默认字号调成 20px 或 24px，还要求按钮文字和间距同步变大，px 就完全失效。
- 所有布局尺寸（
width、padding、margin、font-size）优先用rem，前提是根元素html的font-size已显式设置（不要依赖浏览器默认 16px） - 避免在
rem计算中混用em—— 比如父容器用em设了font-size，子元素再用rem，基准就乱了 - JavaScript 动态改字号时，只改
document.documentElement.style.fontSize，别碰body或其他节点的font-size
% 高度为什么经常不生效
height: 100% 失效不是 bug，是 CSS 规范行为：百分比高度必须有明确的“计算上下文”，即父容器的 height 必须是确定值（px、vh、rem 等），不能是 auto 或未声明。
- 常见错误：
.container { height: 100%; }但它的父级没设height，结果就是 0 - 正确做法：往上追到
html和body，加height: 100vh;或min-height: 100vh; -
%更适合宽度控制（父宽通常可推导），高度尽量用vh或flex: 1替代
vw/vh 在移动端的实际坑
vw 看似简单（1vw = 视口宽的 1%），但在 iOS Safari 和部分安卓 WebView 中，地址栏展开/收起会动态改变视口高度，导致 100vh 不等于屏幕物理高度 —— 页面可能被截断或留白。
- 真机测试必做：滚动页面，看地址栏隐藏后
vh区块是否跳动 - 安全替代：
100dvh（dynamic viewport height）已进入标准，Chrome 105+、Safari 16.4+ 支持，但老版本需降级为100vh+ JS 补偿 -
vw做字体时慎用：小屏下4vw可能只有 12px，阅读困难；建议配合clamp()限制范围，如font-size: clamp(14px, 4vw, 20px);
如何让相对单位真正“响应”而不是“摆样子”
很多模板写了 rem 和 vw，但没考虑用户真实操作路径：比如缩放到 200%，触控区域是否仍满足 WCAG 的 44×44px 最小点击区？图标变大了，但 padding 还是写死 8px，实际点击热区就缩水了。
- 所有可交互元素（按钮、链接、表单项）必须设
min-width和min-height，且值用rem或px（不能只靠%） - 字体大小用
rem，但行高、内边距也得同步用rem，否则缩放后文字挤出容器 - 用 Chrome DevTools 的 Rendering → “Emulate CSS media features” 测试不同
prefers-reduced-motion和forced-colors场景，别只盯着宽度变化
最常被忽略的一点：相对单位的效果，永远受限于它所依赖的那个“基准”是否稳定。根字体变了，rem 才真响应；视口高度变了，vh 才真可用；父容器尺寸定了，% 才真计算。不检查这些前提，光换单位只是自我安慰。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
