写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-systemmacOS/iOS的UI字体显示效果最贴合系统2BlinkMacSystemFont旧版Chrome/Safari对-apple-system的补充写法3Segoe UIWindows 8的界面字体英文数字干净4Helvetica Neue / Helvetica / Arial老牌西文字体兜底5PingFang SC苹方macOS/iOS的中文主力6Hiragino Sans GB冬青黑体部分macOS系统的旧版中文回退7Noto Sans SC思源黑体跨平台开源方案8Microsoft YaHei微软雅黑Windows中文主力9sans-serif最后兜底保证一定是无衬线这套栈不是最优解因为“最优”在不同系统上不一样但它在任何系统上都不会让人感觉突兀。你不需要背下来理解排列原则之后自己也能根据项目平台去增删。3. font-size的单位选择题px、em、rem、vw与clamp()到底怎么搭配3.1 为什么排版的基准字号推荐用16px或1remfont-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 stylefont-size: 1.2em; !-- 16 * 1.2 19.2px -- div stylefont-size: 1.2em; !-- 19.2 * 1.2 23.04px -- div stylefont-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等于400bold等于700。数值范围是1~1000其中常用的几个档位如下数值通用名称是否常见100Thin / Hairline少见200Extra Light少见300Light部分有400Regular / Normal常见500Medium部分有600Semi Bold / Demi Bold少见700Bold常见800Extra Bold少见900Black / 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会被重置成400font-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问题。真有品牌定制需求优先选可变字体配合子集化方案把文件体积和字重灵活性都掌握在自己手里。文字排版这件事看着基础但把字体选择的每一个环节都想清楚页面质感会完全不一样。