rem单位通过相对于根元素字体大小实现全局统一缩放，设置html font-size为62.5%使1rem=10px，简化计算；结合媒体查询可实现响应式设计，提升可访问性与维护性，适用于字体、布局及间距，构建一致性UI系统。
在CSS中，
rem（root
em）是一个相对长度单位，它相对于HTML文档的根元素（
<html>）的字体大小来定义。这意味着，无论你在页面结构中的哪个位置使用
rem，它都会参照最顶层
<html>元素的
font-size来计算实际的像素值，从而提供了一种全局且易于管理的字体缩放机制。
解决方案
rem的核心魅力在于其全局统一的缩放能力。要有效利用
rem，我们通常会先设置一个基准值。一个非常常见的做法是将
<html>元素的
font-size设置为
62.5%。为什么是
62.5%？因为浏览器默认的
font-size通常是
16px。
16px * 62.5% = 10px。这样一来，
1rem就等同于
10px，这极大地简化了我们后续的计算：如果设计稿上是
18px，那么在CSS中直接写
1.8rem即可，心算起来非常方便。
/* 设置基准字体大小 */
html {
font-size: 62.5%; /* 1rem = 10px */
}
/* 页面中的其他元素就可以直接使用 rem */
body {
font-size: 1.6rem; /* 相当于 16px */
line-height: 1.5;
}
h1 {
font-size: 3.2rem; /* 相当于 32px */
margin-bottom: 1.5rem;
}
p {
font-size: 1.4rem; /* 相当于 14px */
}
.button {
padding: 1rem 2rem; /* 按钮内边距也使用 rem */
font-size: 1.6rem;
}这种设置方式的优势在于，当你需要调整整个页面的字体大小（比如为了响应式设计或用户偏好），你只需要修改
<html>元素的
font-size，页面上所有使用
rem的字体大小都会按比例自动调整，而不会出现
em单位那种层层嵌套、难以预测的累积效应。这让我作为开发者感到非常安心，因为它大大降低了维护成本和潜在的布局问题。
为什么说 rem
是实现响应式字体和可访问性的理想选择？
在我看来，
rem之所以被推崇为响应式字体和可访问性的理想选择，主要在于它提供了一种“全局控制”的能力。想象一下，一个网站需要适应从手机到超宽屏显示器的各种设备，如果所有字体大小都用
px固定死，那将是一场灾难。你需要写大量的媒体查询，针对每个断点逐个调整字体大小，这不仅工作量巨大，而且容易出错。
立即学习“前端免费学习笔记（深入）”；
rem改变了这一切。通过在媒体查询中仅仅调整
html元素的
font-size，整个页面的字体大小就能按比例缩放。比如，在小屏幕上，你可以将
html { font-size: 50%; }，那么之前 1.6rem的字体就会从
16px变为
8px（如果基准是
16px），或者从
16px变为
12.8px（如果基准是
10px）。这种一石多鸟的策略，让我能更专注于内容和布局本身，而不是被繁琐的字体调整细节所困扰。
更重要的是，
rem对可访问性的贡献是
px望尘莫及的。很多用户，特别是视力不佳或有阅读障碍的用户，会通过浏览器设置来调整默认字体大小。当你的网站使用
px时，这些用户的设置往往会被忽略，导致内容难以阅读。但
rem是相对于浏览器默认字体大小的，这意味着如果用户将浏览器默认字体从
16px调整到
20px，你的
1rem也会相应地从
10px（假设你设置了
62.5%）变为
12.5px，所有使用
rem的字体都会随之放大，完美适配用户的个性化需求。这种对用户体验的尊重，是我坚持使用
rem的一个重要原因。它不仅仅是技术上的选择，更是设计理念上的体现。
在实际开发中，如何更高效地管理和计算 rem
值？
在实际开发中，虽然
62.5%的技巧让
rem的计算变得简单，但面对大量的
px值转换，或者在团队协作中保持一致性，还是需要一些策略。我个人常用的方法是结合预处理器和一些辅助工具。
首先，
62.5%这个基准设置几乎是我的标配。它让
1rem = 10px成为一种直觉，看到
1.8rem我就知道是
18px，这大大减少了心算或查表的时间。但即便如此，在处理一些细致的像素值时，手动转换还是有点烦。
这时候，CSS 预处理器（如 Sass、Less 或 Stylus）就派上用场了。我通常会定义一个
px-to-rem的混合宏（mixin）或函数。
// Sass 示例
$browser-context: 16; // 浏览器默认字体大小
$rem-base: 10; // 1rem = 10px
@function rem($pixels) {
@return ($pixels / $rem-base) * 1rem;
}
// 使用
.my-element {
font-size: rem(18); // 输出 1.8rem
padding: rem(10) rem(20); // 输出 1rem 2rem
}
// 如果你没有设置 html { font-size: 62.5%; }，而是保持浏览器默认 16px，
// 那么函数会是这样：
// @function rem($pixels) {
// @return ($pixels / $browser-context) * 1rem;
// }
// 这种情况下，18px 会是 1.125rem，计算起来就没那么直观了。
// 所以我还是偏爱 62.5% 的基准。有了这样的工具，我可以直接在 Sass 中使用
px值，让预处理器在编译时自动转换为
rem。这既保留了
px的直观性，又享受了
rem的优势。对于一些快速迭代的项目，或者需要处理遗留
px代码时，这种方法尤其高效。
此外，一些现代的IDE插件，比如 VS Code 的
px-to-rem插件，也能提供实时转换或快捷键转换功能，这在写 CSS 时能省去不少麻烦。我发现，这种工具的辅助让我能够更专注于设计本身，而不是被单位转换这种机械性的工作所困扰。
除了字体大小，rem
在布局和间距方面有哪些应用潜力？
rem的潜力远不止于字体大小。当我们将
rem扩展到布局和间距（如
margin,
padding,
width,
height,
border-radius等）时，我们实际上是在构建一个基于单一基准的、高度一致且可扩展的UI系统。
设想一下，你有一个卡片组件，它的内边距是
16px，底部外边距是
24px，宽度是
300px。如果用
px来写，那么在响应式调整时，你可能需要针对不同屏幕尺寸分别调整这些
px值。但如果都用
rem呢？
.card {
padding: 1.6rem; /* 16px */
margin-bottom: 2.4rem; /* 24px */
width: 30rem; /* 300px */
border-radius: 0.4rem; /* 4px */
}当你在媒体查询中调整
html的
font-size时，这个卡片组件的
padding、
margin-bottom、
width乃至
border-radius都会按比例缩放。这意味着，整个组件的视觉比例和相对大小都将保持不变，只是整体上变大或变小了。这种“整体缩放”的能力，对于构建一致的用户界面和设计系统来说是极其宝贵的。它强制我以相对的眼光去看待设计元素之间的关系，而不是固定死的像素值。
这种做法的好处是显而易见的：
- 全局一致性： 整个UI的缩放都围绕一个中心点进行，视觉节奏和间距更加统一。
-
维护性提升： 需要调整整体UI大小？只需改动
html
的font-size
。 - 更好的可访问性： 用户调整浏览器默认字体时，不仅字体会变大，整个布局也会相应调整，确保内容和交互元素不会挤压或错位，提供更友好的体验。
我的经验告诉我，一旦你开始用
rem来定义布局和间距，你就很难再回到纯
px的世界了。它让我在思考设计时，更多地考虑元素间的相对关系和整体的流动性，而不是被像素的绝对值所束缚。这不仅是编码方式的改变，更是设计思维上的一次升级。当然，这并不是说
px就一无是处，对于一些需要精确到像素的边框、图标大小等，
px依然有其存在的价值。关键在于理解它们的特性，并根据实际需求做出最合适的选择。
