写CSS写了这么多年，我见过不少项目第一个崩掉的地方不是布局，也不是动画，而是这几个看起来人畜无害的字体属性。最典型的场景：设计师在稿子里给了一个300号的细字重，你在代码里写下font-weight: 300，打开页面发现纹丝不动；又或者你认认真真在font-family里写了三四个字体，页面最终还是落到了系统宋体上；再或者，仅仅因为用了一次font复合属性，前面辛苦设置的line-height直接被重置。这些问题有一个共性——CSS字体属性表面上是“设置一下”就行，背后其实牵涉字体栈回退、字重映射、字体文件加载、字体度量对齐这四层机制。
这篇文章我准备把这几个属性一次讲透。不背文档，不记语法表，而是从实际渲染原理出发，把字体系列、字体大小、字体粗细、文字样式、字体复合属性真正吃透。不管你是刚入门CSS的新手，还是写了几年页面想查漏补缺的老手，这篇都值得花十分钟看完。
1. 一个反直觉的事实：字体属性越简单，翻车率反而越高
先说说为什么这几个属性容易出问题。
单独看任何一个属性，语法都非常短：font-family就是指定字体名，font-size就是设置字号，font-weight就是设粗细，font-style就是设斜体。背下来可能半小时都不用。但真实项目里，问题从来不出在“不知道属性名”，而是出在“属性和渲染结果是两回事”。
举个例子。你在Windows上用Chrome打开一个页面，页面只写了：
body { font-family: "PingFang SC", "Microsoft YaHei", sans-serif; }第一眼看上去没什么问题。苹方是macOS的字体，Windows上没有，浏览器会跳过；微软雅黑Windows上有，正常应该用雅黑渲染。但如果你在样式表前面多写了一个引号，或者把字体名写成了“微软雅黑”和“Microsoft YaHei”混用，在某些内核版本下就可能直接落到sans-serif，最后显示成默认宋体。你检查了半天属性名，发现完全正确，就是不知道哪儿不对。
再比如font-weight。大部分前端都知道它有100到900九个数值，但翻开系统字体的真实文件，微软雅黑只有400和700两个档，苹方多一些，有5个档左右。当你写font-weight: 300的时候，浏览器找不到300的字重文件，会自动“合成”一个，或者就近映射到400。合成出来的细体，远看还行，放大看基本就是normal字重做了个减淡处理，根本不是设计师要的Light效果。
还有font复合属性。这是最容易被忽略的坑。font: 16px "Helvetica", sans-serif;这句看起来只是设置了字号和字体，实际上它会把font-style、font-weight、font-variant、line-height全部重置为初始值。如果你之前在某个类里写了一个斜体，后面不小心用了一次复合属性，斜体就没了。
所以我想先给一个完整的心智模型，方便你把后面的内容对号入座。一个文字从你写完CSS到最终显示在屏幕上，会经过四个环节：
- CSS声明解析：读取
font-family、font-size这些属性值； - 字体匹配与回退：浏览器拿着字体名去系统字体库挨个查找，找不到就按顺序回退；
- 字体文件加载：遇到Web Font，还得通过网络把字体文件拉下来，这中间有延迟、有阻塞策略；
- 字体度量与布局：字体文件里自带ascent、descent、line gap等度量值，这些值决定了行高、基线、文字是否居中。
后面每一个章节，其实都是在某一个环节里去解决问题。
2. font-family不是“选个字体”：字体栈的回退逻辑与中文环境下的书写习惯
2.1 字体栈为什么要把西文字体放在中文字体前面
font-family的值可以写多个字体名，用逗号隔开，这一串东西叫“字体栈”。很多新手以为字体栈就是多列几个字体做保险，第一个没有就换第二个，这理解本身没错，但忽略了一个更重要的细节：字体选择是按字符走的，不是按整个页面走的。
也就是说，浏览器不是把“整个文本”交给某一个字体去渲染，而是逐个字符去匹配。遇到一个字符，先去字体栈第一个字体里找，找到了就用第一个；找不到再去第二个里找。这就是为什么字体栈的第一个字体非常关键。
你可能会问：那为什么大家总是推荐把西文字体放在中文字体前面？比如这样：
font-family: "Helvetica Neue", Helvetica, Arial, "PingFang SC", "Hiragino Sans GB", "Noto Sans SC", "Microsoft YaHei", sans-serif;原因在于：中文字体本身就包含拉丁字母的字符。你用"PingFang SC"渲染英文“Hello”，它也能显示，而且苹方的拉丁字形并不算丑，但和专门的西文字体Helvetica、Arial相比，数字、字母的细节处理还是有差距。把西文字体放在前面，英文和数字优先用西文字体渲染；中文字符因为西文字体里没有，自动落到后面的中文字体上。这样混排出来的效果，英文更精致，中文也正常，两头都占。
这个原则在真实项目里非常实用。很多设计稿要求英文数字用品牌字体，中文用系统字体，你根本不需要在标签上手动加class，字体栈的顺序就已经能实现。
2.2 中文字体的双轨命名、引号规则与通用族陷阱
中文字体的命名有一个相当烦人的问题：同一个字体，在CSS里有两种写法都能用，但兼容性不一样。
以微软雅黑为例。中文写法是"微软雅黑"，英文写法是"Microsoft YaHei"。Windows上两种写法都能识别，但如果你把页面部署到macOS上，系统里只装了某个版本的雅黑时，“Microsoft YaHei”这种英文名的命中率往往更高。反过来，苹方的写法"PingFang SC"是英文名，但macOS和iOS都能识别。遇到"苹方"这种中文别名，部分老版本系统就不认了。
所以我的习惯是：在中文字体栈里尽量用字体的英文名，特殊情况下再补一个中文名兜底。这样做还有一个额外的好处——避免中文和引号混在一起时，编码或转义出问题。
再来说引号。字体名如果包含空格、数字或中文，建议用引号包起来，比如"Helvetica Neue"、"PingFang SC"、"Microsoft YaHei"。但通用族名不是具体字体，它们是一类字体的统称，包括serif、sans-serif、monospace、cursive等。通用族名绝对不能加引号。一旦写成"sans-serif"，浏览器就会把它当成一个名叫“sans-serif”的具体字体去找，找不到就回到默认字体，很可能把无衬线界面打成宋体。这个问题在团队协作时特别容易埋雷，因为老代码里的引号不一定是谁加的，排查起来还挺费劲。
2.3 一套跨Windows/macOS/移动端的稳妥字体栈
基于上面的逻辑，我给一个自己项目里长期使用的字体栈模板：
body { font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", "Helvetica Neue", Helvetica, Arial, "PingFang SC", "Hiragino Sans GB", "Noto Sans SC", "Microsoft YaHei", sans-serif; }逐个说下这样排的理由：
| 位置 | 字体 | 原因 |
|---|---|---|
| 1 | -apple-system | macOS/iOS的UI字体，显示效果最贴合系统 |
| 2 | BlinkMacSystemFont | 旧版Chrome/Safari对-apple-system的补充写法 |
| 3 | Segoe UI | Windows 8+的界面字体，英文数字干净 |
| 4 | Helvetica Neue / Helvetica / Arial | 老牌西文字体兜底 |
| 5 | PingFang SC | 苹方，macOS/iOS的中文主力 |
| 6 | Hiragino Sans GB | 冬青黑体，部分macOS系统的旧版中文回退 |
| 7 | Noto Sans SC | 思源黑体，跨平台开源方案 |
| 8 | Microsoft YaHei | 微软雅黑，Windows中文主力 |
| 9 | sans-serif | 最后兜底，保证一定是无衬线 |
这套栈不是最优解，因为“最优”在不同系统上不一样，但它在任何系统上都不会让人感觉突兀。你不需要背下来，理解排列原则之后，自己也能根据项目平台去增删。
3. font-size的单位选择题：px、em、rem、vw与clamp()到底怎么搭配
3.1 为什么排版的基准字号推荐用16px或1rem
font-size的单位选择，是我在面试里最喜欢问的问题之一。很多人能用，但说不清为什么。
px是最直观的绝对单位。16px在Web上基本是浏览器默认字号，大多数系统里浏览器默认正文大小就是16px。用px的好处是所见即所得，设计稿标多少写多少；坏处也很明显，用户如果在浏览器里设置了“更大字号”来辅助阅读，px不会跟着变，这对可访问性不友好。
rem是相对单位，相对于根元素<html>的字体大小。默认情况下根元素的字号是16px，所以1rem等于16px。如果用户调整了浏览器字号，或者你通过媒体查询改了根字号，所有用rem的文字都会等比变化。这也是为什么越来越多团队把正文基准字号定成16px或1rem，然后所有间距、行高、标题都基于这个值去推导。
我自己习惯是根元素不强制改，保持浏览器默认，然后在正文里用rem，局部微调用px。这样既能跟随用户设置，又不会让间距和边框也一起乱掉。
3.2 em的继承陷阱与反向利用
em是相对父元素的字号。单层看很直观：父元素字号16px，子元素font-size: 1.2em就是19.2px。但嵌套多层之后，问题就来了：
<div style="font-size: 1.2em;"> <!-- 16 * 1.2 = 19.2px --> <div style="font-size: 1.2em;"> <!-- 19.2 * 1.2 = 23.04px --> <div style="font-size: 1.2em;"> <!-- 23.04 * 1.2 = 27.648px --> 文字 </div> </div> </div>很多新人以为每一层都是16px的1.2倍，实际上em会逐层累积。层级一深，字号就像滚雪球一样失控。所以em用在正文排版里风险比较高，我更推荐把它用在某个局部组件的内部，让组件相对自身的基准字号等比变化。
反向利用em其实很舒服。比如做一个新闻标题列表，希望标题随正文容器字号等比缩放，你可以只调整容器字号，标题用em就能跟着动，不用写一堆媒体查询。关键是想清楚应用边界。
3.3 rem的移动端适配逻辑与根字号调整
移动端适配经典方案里，有一种是动态修改根字号。比如拿到设计稿宽度750px，把根字号设成clientWidth / 10，这样1rem就等于屏幕宽度的十分之一。设计稿上量到多少px，除以75就能换算成rem。本质上是用rem把整个页面改造成一个按视口宽度等比缩放的系统。
但这种方案今天不是唯一解，甚至不是最优解。vw可以直接取视口宽度的百分比，配合calc()，很多时候比改根字号更轻量。比如想做一个随视口变大而变大的标题：
h1 { font-size: calc(1.5rem + 2vw); }1.5rem是基础尺寸，2vw是增速。视口越宽，2vw贡献的像素越多，标题会平滑地变大。拆开看就是一条线性增长公式。
这套写法的好处是保留rem的可访问性基础，又获得了响应式能力。比写三四个媒体查询更省心。
还要留意一个真实存在的坑：浏览器有最小字号限制。Chrome的默认最小字号一般不低于10px，你在代码里写font-size: 8px，真机上按最小字号渲染，可能导致本来一行能放下的内容被撑破。设计稿上的小字，和浏览器渲染出来的实际结果，经常是两回事。
3.4 clamp()流体字号的计算思路
clamp()让流体排版更进一步，它接受三个参数：最小值、首选值、最大值。
h1 { font-size: clamp(1.5rem, 0.5rem + 2vw, 3rem); }意思是：最小1.5rem，最大3rem，中间按0.5rem + 2vw线性变化。当视口变宽时，字号跟着变大，但到了3rem就封顶，不会无限膨胀。
在实际落地时，我一般不会精确去解方程算每个断点的vw值，而是先定一个中等视口下的理想字号，然后看它在手机竖屏是否太小、在大屏是否太大，微调一下系数就行。比如中间值算出来越界了，就降低vw前的系数。这个调参过程最多两三轮，比维护一堆媒体查询舒服很多。
下面用一张表总结这几种单位的适用场景：
| 单位 | 相对对象 | 优点 | 主要风险 | 推荐场景 |
|---|---|---|---|---|
| px | 视口/设备像素 | 精确、直观 | 不跟随用户字号设置 | 边框、固定装饰、小图标 |
| em | 父元素 | 局部等比方便 | 嵌套累积失控 | 组件内部、模块内细节 |
| rem | 根元素 | 可全局缩放 | 需规划根字号策略 | 正文、标题、间距体系 |
| vw/vh | 视口 | 天然响应式 | 极端屏幕下可能失控 | 大标题、首屏视觉 |
| clamp() | 混合 | 两头受控、平滑 | 写法稍绕 | 响应式标题 |
4. font-weight的“数字幻觉”：100~900在系统字体里大多并不存在
4.1 数值字重与系统字体的真实匹配
先说font-weight支持的值。关键字的对应关系是：normal等于400，bold等于700。数值范围是1~1000，其中常用的几个档位如下：
| 数值 | 通用名称 | 是否常见 |
|---|---|---|
| 100 | Thin / Hairline | 少见 |
| 200 | Extra Light | 少见 |
| 300 | Light | 部分有 |
| 400 | Regular / Normal | 常见 |
| 500 | Medium | 部分有 |
| 600 | Semi Bold / Demi Bold | 少见 |
| 700 | Bold | 常见 |
| 800 | Extra Bold | 少见 |
| 900 | Black / Heavy | 少见 |
问题来了：你在Windows上安装的微软雅黑，实际只有400和700两个字重文件。你在CSS里写font-weight: 500，系统里没有500，浏览器会执行一套字重映射规则，而不是老老实实给你显示500。
映射规则大致是：当指定字重不可用时，如果数值大于500，就找最近的更粗字重；如果数值小于400，就找最近的更细字重。400和500之间有特殊性，为了满足medium的需求，浏览器会在这两者之间择近匹配。结果就是，你写500，可能出来的是400；你写600，可能出来的是700。这就是“数字幻觉”——你指定了一个数字，页面也用了一个数字，但两个数字不是同一个东西。
所以，在选用字体前，先去确认字体文件到底有哪些字重。如果设计稿用到300和500，而系统字体只有400和700，那就要么换字体，要么引入Web Font，要么接受浏览器自己的近似处理。
4.2 字重回退时的“就近原则”细节
这个就近原则具体怎么就近，不同浏览器实现略有差异，但大致思路一致：在可用字重里，找一个和目标数值最接近的。区别在于“更近”的定义。当没有完全一致的匹配时，有的引擎会优先取较粗的字重，有的会取较细的。这也是为什么同一套代码在Chrome和Safari里，字重的肉眼观感可能不同。
如果你希望用户看到的效果稳定，不要在字重选择上过度依赖系统字体的冷门档位。能用400和700解决的就不要硬写300。要么就用字体文件控制得更死一点——具体来说就是走可变字体或Web Font。
4.3 font-synthesis要不要禁
font-synthesis控制浏览器是否允许合成（synthesize）不存在的字重和斜体。当字体没有加粗档，浏览器又遇到font-weight: bold时，它会默认直接做“伪加粗”——也就是把普通字形的笔画往外扩一圈。细分场景下，这种伪加粗在低分辨率屏幕上会有明显的锯齿，尤其在中文里特别难看。
你可以关掉：
font-synthesis: none;这样浏览器不会自己合成加粗或斜体，宁可显示普通字形，也不产生劣质效果。代价是某些情况下你明确写了bold，但因为字体确实没有粗体，看起来跟普通字形一模一样。所以这个属性更适合你借助Web Font把字重控制到位的时候用，用来清除浏览器多管闲事的那一下。
4.4 可变字体：让字重真正连续起来
想彻底摆脱字重断层，方案是可变字体。一个字体文件里包含整个字重轴，400到700之间每一个值都能精确渲染，不存在“找不到对应文件”的问题。
通过font-variation-settings可以直接控制：
h1 { font-variation-settings: "wght" 650; }更现代的做法是直接配合font-weight使用。声明可变字体时，可以在@font-face里指定取值范围：
@font-face { font-family: "MyVariableFont"; src: url("MyVariableFont.woff2") format("woff2-variations"); font-weight: 100 900; }之后你写font-weight: 450或者font-weight: 620，都会得到真实对应的字形。对于做品牌官网、需要精确控制字重的项目，可变字体是目前体验和性能兼顾的最佳方案。代价是需要找支持可变字重的字体文件，比如Inter、思源黑体的可变版。
4.5 hover加粗引起的布局跳动
这是热搜词“css 鼠标移入事件”下面最常被问到的字体问题。很多按钮在普通态是font-weight: 400，鼠标移上去变成font-weight: 700。粗体字宽更宽，按钮文字会左右变宽，导致整个按钮或周围布局突然跳一下，特别明显。
应对方案按优先级排序：
- 如果字体有同一家族的不同字重，且宽度相同（现代很多UI字体做了度量统一），这个问题天然不存在；
- 如果不满足，就采用“占位重排”的思路：按钮宽度固定，或者预留足够padding，让加粗后的文本仍然放得下；
- 更精细的做法是普通态用一个
visibility: hidden的粗体占位文本把宽度撑住，这样不管字重怎么变宽度都不动； - 如果项目用了可变字体，可以用
transition配合字重轴做平滑过渡，观感上基本不跳。
但要注意，font-weight并不支持常规的CSS过渡，因为字重是一个离散的字体选择逻辑。可变字体通过font-variation-settings配合特殊的CSS属性可以做到插值动画，而普通字体做不到。所以最省心的还是把宽度预留好。
5. font-style与font复合属性：斜体不是倾斜，缩写也有覆盖风险
5.1 italic与oblique的区别：设计师做的斜体vs浏览器硬掰
font-style有三个值：normal、italic、oblique。很多教程会说italic是意大利体，oblique是倾斜体，区别在于“italic更像手写体，oblique只是把正体倾斜”。这个说法没错，但落地时有一个中文环境特有的坑——大部分中文字体压根没有真正的italic字型。
字体设计公司在做西文字体时，会把italic当成一套独立设计，字母结构会调整，不仅仅是倾斜。中文字体因为字形数量大、设计成本高，绝大多数只做正体，没有italic。那么当你在中文内容上写font-style: italic时，浏览器找不到中文字体的斜体文件，就会走合成逻辑，把正体做倾斜变换。这就是为什么中文斜体看起来总是有点“硬掰”的感觉，不如西文斜体自然。
oblique可以带角度，比如：
font-style: oblique 15deg;角度允许范围一般是-90deg到90deg，这个值告诉浏览器按指定角度倾斜。如果你不想看到完全没经过设计师处理的硬掰斜体，可以多考虑oblique加轻角度，视觉上比默认的合成斜体可控一些。也可以用font-synthesis: none彻底禁止伪斜体，但这会让中文的italic直接失效，所以只推荐在完全靠字体文件控制样式的项目里用。
5.2 font缩写规则：哪些能省，哪些必填，省了会怎样
font复合属性的完整语法是：
font: font-style font-variant font-weight font-size/line-height font-family;前三个font-style、font-variant、font-weight是可选的，位置可以互换；但font-size和font-family是必填的，而且顺序固定——font-size必须在前，font-family必须在最后。line-height要跟在font-size后面，用斜杠连接，比如：
font: italic bold 16px/1.6 "Helvetica Neue", sans-serif;看起来方便，但复合属性的覆盖风险非常大。因为所有省略的可选值都会被重置为initial。
举个例子。你先写：
.title { font-weight: 700; font-style: italic; }后面某个地方又写了：
.title { font: 18px "PingFang SC", sans-serif; }那么font-weight会被重置成400，font-style会被重置成normal。你之前辛苦设置的粗体和斜体，全被这一行复合属性干掉了。如果那是hover状态，交互效果就会“莫名其妙”失效。
所以我的建议是：font复合属性只用在需要一次性统一定义的场景，比如body、.btn这类基础组件上。后续要修某一个值，尽量用独立属性，并注意不要和复合属性互相踩踏。更稳妥的做法是，整个项目里规定好：要么统一用复合属性，要么统一用独立属性，不要混着写。
5.3 删除线到底是哪个属性：font与text-decoration的边界
热搜词里有个“css 删除线”，很多人会在font属性里翻半天，想找一个“删除线”的子属性，结果找不到。这里要厘清一个边界：font属性管的是字形本身的排版，字体的家族、大小、粗细、风格；而删除线、下划线、上划线这些，属于text-decoration体系。
.del { text-decoration-line: line-through; text-decoration-color: red; text-decoration-thickness: 2px; }简单写法：
del { text-decoration: line-through; }跟font没有任何关系。类似容易混淆的还有文字外描边（-webkit-text-stroke）、字体渐变（background-clip: text配合color: transparent）和文字阴影（text-shadow），这些都属于文本装饰或背景处理，不要把它们往font属性里塞。
6. 中文字体加载性能与表单文本对齐：字体属性之外的最后一公里
6.1 中文字体几MB，不能按西文字体的玩法来
中文字体文件体积非常大。一套完整的思源黑体，简体+繁体可以到10MB以上，一个西文字体往往只有几十KB到几百KB。如果直接把它塞进@font-face，用户打开页面的瞬间就要下载一个10MB的文件，这在移动端是完全不可接受的。
解决方案是子集化。把字体文件按需要拆成小份，只保留页面里出现的字符。常用工具包括font-spider、fontmin、glyphhanger等，它们会扫描你的HTML/CSS/JS，提取出实际用到的字符，生成精简后的woff2文件。比如一个宣传页可能只用了200个汉字，子集化之后字体文件可能只有几十KB，加载体验完全不一样。
更进一步的做法是用unicode-range把字符分为多个片段。比如常用3500字放一个文件，生僻字、冷门标点放另一个文件，浏览器遇到某个字符才会去下载对应的分片。配合WOFF2压缩，中文字体的性能压力可以摊薄很多。
6.2 font-display四档策略与FOUC
引入Web Font后，浏览器必须先下载字体文件，才能渲染对应文字。在字体文件没下载完之前，页面有两种表现：要么空白，要么先用回退字体显示。这个空白期或闪变期，就是Font Flash现象。
font-display属性专门控制这个阶段的行为，常见四档：
| 值 | 阻塞期 | 交换期 | 效果 |
|---|---|---|---|
| auto | 跟随浏览器默认 | 跟随浏览器默认 | 不可控 |
| block | 最长3秒 | 无限 | 先白屏，字体加载完再显示 |
| swap | 极短 | 无限 | 先显示回退字体，字体加载完替换 |
| fallback | 约100ms | 约3秒 | 短暂等待，超时后固定用回退字体 |
| optional | 极短 | 不替换 | 快速显示回退，不阻塞渲染 |
对正文这种大量文字，我一般用swap，确保用户能立刻看到内容，字体加载完再平滑替换。对标题这种视觉核心，可以用fallback，给它一点等待时间，但不会让用户等太久。最忌讳的是block，白屏几秒钟对大部分用户来说就是流失。
6.3 字体度量与input文本不垂直居中的真相
“css中怎么把input居中”是又一个高频热搜词。很多人的感受是，明明给input设置了固定的height和line-height，文字还是偏上或偏下，怎么都对不齐。
这背后的深层原因，是字体的度量数据。每个字体文件里都记录了ascent、descent、line gap这组数值，它们决定了文字内容在行框内的实际位置。不同字体、即使字号相同，这些数值也可能差异很大。你用line-height去控制垂直位置时，其实是在控制整个行框的高度，但文字基线在行框里的位置仍然由字体度量决定。所以会出现：字号、行高都一样，换了字体，垂直位置就变了。
给input、button、select、textarea设置文字时，最直接的办法是先统一字体：
input, button, select, textarea { font-family: inherit; font-size: inherit; line-height: inherit; }这行重置能消灭掉大部分“为什么input里字体和页面不一样”的困惑。更进一步，想要input高度稳定，不要靠height和line-height去挤，而是用padding撑出垂直空间，让文字自然居中：
.input { padding: 8px 12px; border: 1px solid #ccc; }line-height保留默认的normal，比硬凑某个数值更稳。按钮也是同理，Android上按钮文字经常偏上，多半是line-height和字体度量叠加导致，用padding方案能规避大多数平台差异。
6.4 一个顺手的表单字体重置
给一套我日常项目里用的表单控件字体基线，可以直接拿去改：
button, input, select, textarea { font-family: inherit; font-size: inherit; line-height: inherit; margin: 0; } button, input { overflow: visible; } button, select { text-transform: none; }这几条做完，表单控件的字体就和页面正文统一了。之后再去调height、padding、居中，才是真正在调布局，而不是跟浏览器默认样式搏斗。
我在实际项目里还有一个体会：能直接用系统字体栈，就尽量不要自定义中文字体。系统字体加载零成本、渲染稳定、不会有FOUC问题。真有品牌定制需求，优先选可变字体配合子集化方案，把文件体积和字重灵活性都掌握在自己手里。文字排版这件事，看着基础，但把字体选择的每一个环节都想清楚，页面质感会完全不一样。
