前端为什么开始抛弃 px 和 rem，转向 vw 和 clamp()？

做前端开发的小伙伴们不知道有没有注意到：px 和 rem 的使用场景正在被大幅压缩，取而代之的是以 vw 和 clamp() 为代表的现代 CSS 方案。

为什么会有这样的变化呢？也许大家觉得这是技术跟风，其实并不是这么简单，而是一场深刻的范式转移，它标志着我们对“响应式设计”的理解，从“在不同断点间切换”演进为“在任意尺寸下平滑过渡”。

1.先说说老朋友：px 和 rem

px

px 就是像素，绝对单位。

• 好处：简单直接，写多少就是多少。
• 缺点：一旦换了屏幕大小，样式就可能不合适。大屏看太小，小屏看太挤。

rem

rem 是相对单位，基于根元素 html 的font-size。

以前移动端开发时，我们常用 JS 动态设置根字体大小，让所有元素跟着缩放。

例子：

html{
  font-size:calc(100vw/375*16); /*按设计稿宽度换算*/
}

这样一来，写 1rem，在不同设备上会等比缩放。

听起来很棒，但缺点是：

• 需要 JS 脚本支持
• 公式复杂，可维护性差
• 有时字体缩放还会被用户系统设置影响

2.新朋友：vw/vh/clamp()

前端追求的是极致的用户体验和极致的开发效率，rem 的“阶梯式”体验和高维护成本显然无法满足这一要求。于是，以 vw 和 clamp() 为核心的新方案应运而生。

VW (视口宽度单位): 天生的流体基因

vw (Viewport Width) 是一个与视口直接关联的单位，1vw 等于视口宽度的 1%。这意味着，元素的尺寸会随着浏览器窗口的拉伸或收缩，进行实时、平滑、无级的缩放。

.title {
  /* 字体大小永远是视口宽度的 5% */
  font-size: 5vw;
}

这行代码带来的体验是 rem + 媒体查询无论如何也无法模拟的：丝滑的、完全线性的缩放。

但是，vw 也有一个致命缺陷：缺乏边界。在超大屏幕上，5vw 的字体会变得巨大无比；在极小的手机屏幕上，它又可能小到无法阅读。

Clamp(): 终极解决方案，优雅的边界控制

CSS 的 clamp() 函数正是为了解决 vw 的边界问题而生的。它像一个“夹子”，将一个动态的值“夹”在一个最大值和最小值之间。

语法：clamp(MIN, PREFERRED, MAX)

• MIN：最小值，兜底值。
• PREFERRED：理想值，通常是基于 vw 的动态值。
• MAX：最大值，上限值。

让我们用 clamp() 来重写上面的例子：

.title {
    /* 
     * 理想大小为 5vw，但
     * 最小不低于 20px(保证在小屏上的可读性)
     * 最大不超过 50px(防止在大屏上过于巨大)
    */ 
    font-size:clamp(20px，5vw，50px);
}

这一行代码，其实就包含了以往可能需要三到四个媒体查询才能实现的功能，而且做得更好。

3.为什么更推荐现代方案？

1. 更自然的响应式：不用再写一堆媒体查询，纯 CSS 就能随屏幕变化。
2. 更好维护：以前要写各种换算公式，现在一行 clamp()就能搞定。
3. 更贴近设计：现代设计强调“比例感”和“弹性”，vw+clamp 更容易还原。
4. 性能更好：不依赖 JS 动态改样式，浏览器原生支持，渲染效率更高。

4.实际应用场景

• 排版：标题、正文字体用 clamp()，保证大小合适
• 布局：容器宽度用 vw，自然适配不同屏幕
• 间距：margin、padding 用 clamp()控制，既灵活又稳定

5.总结

• px：简单，但固定，不适配
• rem：能缩放，但要写脚本，维护麻烦
• vw/clamp()：浏览器原生支持，自然响应式，可维护性强

以上关于前端为什么开始抛弃 px 和 rem，转向 vw 和 clamp()？的文章就介绍到这了，更多相关内容请搜索码云笔记以前的文章或继续浏览下面的相关文章，希望大家以后多多支持码云笔记。