企业官网建设流程全解析

1. 从一段“不太对劲”的文字说起

在做前端的朋友日常写CSS的时候，字体样式应该是被调得最多、又最容易被轻视的几个属性之一。我经常看到很多新人写的样式表，上来就是一行font-family: "Microsoft YaHei", "宋体", sans-serif;，然后就没有然后了，等到交接维护的时候，后面的同事看着这行声明完全不敢动——改字体怕出了兼容问题，不改字体怕设计稿差太远。其实字体样式这块远没有想象中那么“高深”，它不像Flex布局那样有那么多排列组合的玩法，也不像CSS Grid那样动不动就十几行代码才撑起一个页面骨架，它就是几个属性，但恰恰因为简单，反而留下了很多“随便写写”的空间。这篇内容，我就把字体类型、大小、粗细、样式这四个维度完整拆开，把每个属性背后的原理、参数取舍和实际项目里的调整方式一层层讲清楚。

先说个真实的场景。有个项目里给标题写的字体样式是font-family: 'PingFang SC', 'Microsoft YaHei', Arial, sans-serif;，结果在Windows的Chrome下，英文字符用了Arial，中文字符回退到了雅黑，看起来完全没毛病。但是换了台Mac，PingFang SC本身渲染就很漂亮，又没什么问题。等到了Linux的服务器渲染CSS的截图工具里，字体栈整个失效，直接跳到sans-serif，还在线的页面显得有点“糙”。这个例子说明，字体样式的核心不只是“我写了什么属性”，而是“我给浏览器提供了哪几条退路”“退路之间的优先级是不是合理”。

这篇文章对谁有参考价值？如果你是刚接触CSS没几个月的新手，我会帮你把最基础的概念和参数讲透，做到一看就能上手；如果你已经写了一两年样式，我相信后面关于字体栈策略、字号单位选择、font-weight和font-style的浏览器差异这些内容，能帮你填上很多平时模糊的细节。下面进正文，按属性逐个拆。

2. font-family字体类型有关键信息

2.1 字体栈的基本机制

在CSS里声明字体类型，用的是font-family，这个属性的取值可以是一个名字，也可以是用逗号分隔的一系列名字。浏览器在解析的时候，从第一个开始依次向后检查，如果当前用户的系统里存在这个字体，就用它来渲染对应的文字，如果不存在就继续查下一个，直到找到为止。机制听起来很简单，但真正容易出错的点是选择和排序的逻辑。

我会在项目里这样设计字体栈：

body { font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", "PingFang SC", "Hiragino Sans GB", "Microsoft YaHei", "Helvetica Neue", Helvetica, Arial, sans-serif; }

这种写法的核心思路是照顾不同操作系统。-apple-system和BlinkMacSystemFont是macOS和iOS上的系统字体，写出来之后，系统能自动匹配到苹方，这一条对苹果设备的体验提升非常大。Segoe UI对应Windows新版本的系统界面字体，中文字体栈里我把PingFang SC和Hiragino Sans GB放在雅黑前面，因为同样一段中文，在Mac上优先用苹方渲染，字形更匀称，观感明显好于微软雅黑。Microsoft YaHei负责兜住Windows平台的中文显示，最后用Helvetica Neue和Arial垫底处理英文字符，再往后留给通用家族sans-serif。

从这能总结出一个原则，字体栈要遵循“平台优先、字体回退”的思路。同一个页面在不同系统上显示的字体可以不完全一致，这其实是正常且合理的，因为在可读性和美观性上，系统原生的字体就是最优解，跨平台强行统一字体反而会牺牲渲染质量。字体栈里不需要写几十个字体，但关键平台的常用字体要覆盖到。

2.2 字体家族分类的意义

font-family除了支持具体字体名，还支持五类通用家族，分别是serif、sans-serif、monospace、cursive和fantasy。这个设计被称为最后一道兜底防线，浏览器在找不到所有具体字体以后，会调用用户系统和浏览器设置的默认字体来渲染。

实际项目里，serif和sans-serif用得最多，衬线字体在笔画末端有修饰的小爪，页面里营造传统、正式、印刷感的风格时会用到；无衬线字体更现代、简洁，屏幕阅读也更舒适，所以现代网页绝大多数默认走无衬线路线。monospace等宽字体最常出现在代码块、日志、命令行这类需要垂直对齐的场景，比如展示程序输出或者排版表格数据时，等宽特性对对齐非常友好。

还有一个点值得留意，font-family会把指定的字体作用于所有字符，包括中英文混排的情况。如果指定的字体不含某个字符的对应字形，浏览器就会去后面字重家族里找字形来补位。比如你给段落指定了英文优先字体Roboto，再补一个sans-serif，当遇到中文字符不能被Roboto覆盖的时候，系统会继续向后找，最终落在一个能覆盖中文的字体上。这个回退机制在字体栈里挺重要的，设计和检查时要多看一眼中英文映射是否完整。

2.3 字体名字的引号与中英文细节

font-family属性值里，如果字体名字包含空格，比如Times New Roman，或者形如Microsoft YaHei的体系名字，就必须加上引号。单独一个英文单词的时候，裸写上没有问题，但加了引号也完全合法。我个人的习惯是统一给自定义字体名都加引号，不只是为了避免空格问题，也为了在和@font-face里定义的字体族名做对应时减少拼写错误的风险。

中文字体名称这一块有很多老生常谈但依然有人踩坑的点。Microsoft YaHei是微软雅黑的英文名，在很多老系统里直接写"微软雅黑"也能匹配上，但编码不一致时容易出问题，所以跨平台项目里建议优先用英文名。说到这顺便提醒一下，线上代码里尽量少依赖诸如"宋体"这类直接的中文写法，虽说现代浏览器普遍可以识别，但从字符编码到系统映射的链路里出过太多的诡异问题，有替代方案就不赌这个概率。

如果你的项目要用自定义字体，比如某个设计字体或者特殊品牌字体，完整的流程是通过@font-face注册。这里要指定font-family，同时配合src指向外部字体文件，通常我会准备woff2和woff两种格式覆盖现代和稍老一点的浏览器。注册完毕后再去正文或组件里把它作为字体栈第一位来用。

3. font-size字号处理中值得反复推敲的几个细节

3.1 理解px、em和rem之间的差异

font-size用来设置文字大小，取值的种类非常多，最常用的是px、em、rem，还有百分比、vw/vh这些相对单位。px是最直观的绝对单位，一个px在屏幕上就是一个物理像素点对应的CSS像素，在普通屏幕和Retina屏幕上浏览器会自行做映射处理，所以不用担心模糊。px的问题在于写死在样式表里，页面需要整体缩放或者适配不同屏幕时，如果每个标题的字号都写死，维护起来很痛苦。

em和rem则都是相对单位，em相对于当前元素自身的font-size，容易受父级嵌套影响形成“累积”效应；rem永远是相对于根元素html的font-size，不受中间层影响。我经常用一个例子来说明两者区别，假设根元素字号是16px，某个父容器字号是20px，给子元素写font-size: 2em，最后渲染出的字号就是父容器20px的2倍即40px；但如果写成2rem，浏览器直接拿根元素的16px乘以2，得到32px，完全不理会中间那层20px的影响。实际项目里，rem更适合全局一致的比例体系，em则适合局部稍微缩小或放大的场景，比如按钮内图标和文字的搭配。

3.2 响应式布局下的字号设定策略

移动端适配的时候，很多人习惯用media query在几个断点分别修改根元素的font-size，再把标题、正文全部用rem描述。这个方案本身是稳的，但有一个问题，断点改起来能选的范围比较有限。还有一种更顺畅的做法，用vw单位来设置根元素的字号，让根元素随视口宽度连续变化。比如：

html { font-size: calc(16px + 2vw); }

写法的含义是，基础字号16px，再加上视口宽度2%的增量。屏幕越宽，根字号越大，所有使用rem的子孙元素会跟着一起等比放大缩小。这里要小心的是，大屏上2vw算出来的字体可能会大得过头，小屏上又可能过小，所以通常会再套一层clamp()函数做上下限约束：

html { font-size: clamp(16px, calc(14px + 1vw), 22px); }

clamp接收三个参数，分别是最小值、首选值、最大值，浏览器会在三个值之间取合理结果。这样中小屏不会小于16px，超大屏幕也不会超过22px。用这套逻辑给博客、后台系统换肤，比写死多个媒体查询清爽很多。

3.3 line-height和font-size的搭配关系

字号定了，行高也需要跟着调整。单独设置font-size而不调整行高，默认的行高会造成文字行与行之间要么太挤要么太空。我比较推荐在设置字号时同时显式声明line-height，比如：

p { font-size: 16px; line-height: 1.6; }

line-height可以用数字形式，表示当前字号的倍数，这种写法最佳，因为它不会因为继承链上字号的改变而失效，始终按照自身字号动态计算。日常排版，正文行高在1.5到1.8之间比较舒适，标题因为字号大，行高通常适当压缩到1.2左右。关于中文网页排版，行高直接决定了大段文字的可读性，间距过窄，眼睛在长段落间跳跃容易串行，间距过大，段落整体又会显得松垮，建议多试几个值再定。

4. font-weight的粗细分析和浏览器背后的处理逻辑

4.1 数值与关键字对照

font-weight属性用来控制文字的粗细，最常写的两个值是normal和bold，它们分别对应数字400和700。很多人只知道这两个，但CSS规范里其实给出了一整条从100到900的数值链，每100为一级，依次是Thin、Extra Light、Light、Regular、Medium、Semi Bold、Bold、Extra Bold、Black。在支持可变字体的场景下，字体文件内部包含连续的粗细轴数值，理论上有多少档都可以调出来，但传统字体文件通常只会内置几个固定的字重。

实际操作里一个常见的误区是选了font-weight: 600，但当前字体并没用加载对应的Medium字重文件。此时浏览器并不会报错，而是会在已有字形里找最接近的来渲染。有些浏览器甚至会直接对常规字重做“加粗”处理，也就是把普通字形人为加粗。粗看效果还行，但仔细观察后发现字形变形的痕迹很重，尤其在小字号下糊成一团。所以我处理这种场景时，第一选择是找到对应的字重文件并通过@font-face声明，第二选择是直接用系统里明确存在的那一档，比如直接用700代替600。

4.2 浏览器“合成加粗”与字体“自带加粗”的区别

当CSS声明的font-weight在字体文件里没有对应字形时，浏览器会启动一套合成机制。以Chrome和Firefox为例，它们能根据当前常规字形计算出一个加粗效果，这就叫合成加粗。合成加粗和外部的text-shadow或stroke模拟加粗不太一样，但本质都只是“看起来变粗了”，并不是字体设计师专门绘制的那套粗体字形。

字体自带粗体字形的好处是，笔画粗细按设计稿比例分配，横细竖粗的笔画关系非常讲究，整体节奏舒服。合成加粗的问题是强行给每个笔画加了厚度，圆角的地方突然出现棱角，字的密度不均，中文字体尤其明显。所以写CSS的时候，想要加粗中文标题，最好确保你用的字体栈里存在独立的粗体字重。比如苹方和雅黑都有自带的粗体字形，系统在匹配font-weight: bold时能正确调出对应字重；但如果你的页面里优先字体是有特定字重的英文品牌字体，注意中文字形能否正确回退到合适的粗体。

4.3 定义字体加载时如何避免粗细错乱

用过@font-face的朋友可能会把多个font-family名称分别定义为不同的字体名称来区分粗细，但更好的做法是同一个font-family名称配上多条font-weight。

@font-face { font-family: 'MyFont'; src: url('my-font-regular.woff2') format('woff2'); font-weight: 400; font-style: normal; } @font-face { font-family: 'MyFont'; src: url('my-font-bold.woff2') format('woff2'); font-weight: 700; font-style: normal; }

页面里用的时候，只需要正常写font-family: 'MyFont'; font-weight: 700;，浏览器就能根据字重自动匹配到粗体文件。很多人会写font-family: 'MyFont-Bold'单独当一族，那样也不是不能用，但语义不够准确，后续改字重时往往要连同字体名一起替换，维护成本明显高。

5. font-style斜体样式的底层逻辑与误用

5.1 normal、italic和oblique的差别

font-style属性需要关注的取值主要是normal、italic和oblique。normal就是正常的正体字形；italic指的是真正的斜体，它是字体设计师专门设计的一套带有一定倾斜和书写特征的字形，不只是把正体旋转了一个角度；oblique是程序对普通正体字形做一个倾斜变形得到的结果，字面意义上就是“倾斜”，原理上类似浏览器对不存在的字形做合成处理。

很多新人对这两者的区别体会不深，因为在绝大多数网页字体里，斜体和倾斜渲染出来的视觉差异并不明显。但在衬线字体里，italic与正体的字形差异非常显著，字母的小写形态、衬线细节甚至笔画连接方式都会变化，而oblique只是机械地拉斜，细节上会显得生硬。

5.2 中文环境更容易踩到的坑

中文环境下，中文字体普遍没有专门设计的斜体字形。给中文段落设置font-style: italic，浏览器会把中文字休整体做倾斜处理，也就是走了合成倾斜的路。部分设计场景里确实需要某些中文装饰文本略微倾斜来营造动感，但大段中文正文千万不要设置斜体，阅读体验会直线下降，原本方正的笔画被压扁拉伸，辨识度变低。

还有一种情况是韩文和某些少数民族文字，斜体字形的处理各有差异。总之，在代码里使用font-style: italic之前，先确认当前文字用的字体有没有对应的斜体字形，尤其是多语言站点，建议在字体栈末尾加上通用家族兜底，至少保证主体可读。控制台、代码块等环境通常保持正体，仅在需要强调时使用局部斜体。

另外要注意复选框、伪元素图标之类的场景。有些项目用字体图标库，里面i标签配合font-style默认为italic，如果加载了字体图标，正常情况图标不应该继承斜体样式。最稳妥的办法是对字体图标全局打上font-style: normal;。

6. 把这四个属性组合到一起的实战经验

6.1 一份推荐的全局样式基线

四个属性说完了，接下来关键的是如何在项目里搭建一套协调的排版方案。我一般会先把基准样式放在:root或html里，例如：

:root { font-size: 16px; --font-sans: -apple-system, BlinkMacSystemFont, "Segoe UI", "PingFang SC", "Hiragino Sans GB", "Microsoft YaHei", "Helvetica Neue", Helvetica, Arial, sans-serif; --font-mono: "SF Mono", "JetBrains Mono", Consolas, "Courier New", monospace; } body { font-family: var(--font-sans); font-size: 1rem; font-weight: 400; font-style: normal; line-height: 1.6; }

这个写法有几个好处，把字体栈抽象成CSS变量，后续项目里其他组件复用同一个字体栈时，改一处就能全局生效。基线里同时把font-style重置成normal，防止浏览器默认的italic干扰。需要代码块的时候，再单独用font-family: var(--font-mono)切换，字号和行高可以保持一致，视觉上也整齐。

6.2 标题字号的阶梯设计

很多页面风格不统一，根本原因是标题的四个属性各写各的，没有形成阶梯。我习惯在组件库或页面样式里规划好h1到h6的字号比例，比如采用一个简单的比例尺：

h1 { font-size: 2rem; font-weight: 700; line-height: 1.25; } h2 { font-size: 1.5rem; font-weight: 600; line-height: 1.3; } h3 { font-size: 1.25rem; font-weight: 600; line-height: 1.4; } h4 { font-size: 1rem; font-weight: 600; line-height: 1.5; }

这种用rem描述的比例配合clamp()定义根字号，能在大屏幕上自动放大梯队而不破坏层次关系。font-weight方面，h1和h2通常分别用700和600，这样标题之间既有区别又不至于全部糊成一片黑。如果你的字体没有600这一档，就用500或者直接700，挑一个视觉上最舒服的数值。

6.3 实际项目里综合调整的几条心得

第一条心得，中英文混排时，中文字号和英文字号在视觉上不完全一致，英文字体的x-height通常更小，看起来比同字号的中文小一点。为了让视觉平衡，可以在英文突出展示时稍微把字体调大半档，或者给英文包裹层单独加一小段font-size。

第二条心得，做后台管理系统或数据大屏时，字号选择要更保守一点，通用建议正文最小不要低于12px，低于这个值浏览器容易出现模糊或强行缩放的现象，对用户体验影响很大。另外数字和单位排版建议使用等宽字体，这样表格里的金额、数量上下对齐更规整，这也是font-family在font-size之外的一个隐藏价值。

第三条心得，CSS写完之后记得在多个平台过一遍。同一套字体栈，在macOS上可能全部命中苹方，在Windows上全部命中雅黑，但到了某些Linux服务器或嵌入式场景，字体缺失会导致整体显示掉档。可以借助浏览器的开发者工具来临时调整字体栈，把字体移除几个看看回退效果是否符合预期。多留一步兜底，页面在真实用户环境下的表现会稳定很多。

7. 常见问题速查

我自己的经验是，大部分字体样式问题都不是“我不知道这个属性”，而是“我对字体渲染的理解不够完整”。多花一点时间把字体栈、字号单位、字重映射和斜体机制梳理清楚，再配合实际机型的预览检查，排版效果基本能稳定达到设计稿预期。希望这篇内容对你有用，下次写样式的时候，不妨先停一下，想想字体栈的第一选择真的是你想要的吗。