企业官网建设流程全解析

很多刚接触前端的同学第一次写font-family，多半是复制一行类似font-family: Arial, Helvetica, sans-serif;就完事了。等做到中文项目、移动端适配、邮件模板这些场景，才发现字体这件事远不是写几个字体名那么简单：同样的代码在Windows和macOS上显示完全不一样，明明指定了字体却不生效，中英文混排时字体优先级乱套……这篇文章我就把这些年折腾字体样式踩过的坑、试过的方案一次性讲清楚，从浏览器匹配字体的底层逻辑，到可以直接抄走的中英文font-family方案，再到web font的性能优化和调试思路，全部按实际项目里的使用顺序来。

1. 先弄明白font-family的匹配机制，后面所有配置才有依据

很多所谓"字体不生效"的问题，根源不是代码写错，而是不理解浏览器到底是怎么根据你给的font-family列表去选字体的。先把这条规则吃透，比背一百个字体栈模板都有用。

1.1 浏览器逐字体向下找的规则

font-family可以接收一个或多个字体名，用逗号分隔，越靠前的优先级越高。浏览器渲染文字时，会从第一个字体名开始，逐个检查这个字体在当前系统上是否存在，存在就用，不存在就跳到下一个。这个检查不是"名字对上了就用"，而是要看这个字体里到底有没有当前文字对应的字形。

举个最常见的例子：你写font-family: "PingFang SC", "Microsoft YaHei";并渲染一段中文，macOS上会命中苹方，Windows上没有苹方就落到微软雅黑。但如果你渲染的是一段英文，即使系统里装着微软雅黑，微软雅黑本身也带了拉丁字母字形，所以英文部分依然会用微软雅黑渲染，不会因为"它是中文字体"就自动跳过。这就是为什么做中英文混排时，我们通常把英文字体放在中文字体前面——让英文先命中更好看的西文字体，中文再落到后面的中文字体上。

还有一点要注意：字体名不区分大小写，但引号的使用有讲究。单个英文单词的字体名可以不写引号，例如font-family: Arial；只要字体名包含空格或中文字符，就必须加引号，例如"Microsoft YaHei"、"PingFang SC"、"Noto Sans CJK SC"。很多新手在Windows上写微软雅黑不写引号，结果整个字体声明全部失效，就是这个细节坑的。

1.2 字体栈末尾的通用字体族为什么不建议省

常看别人代码会发现字体栈最后总会跟一个sans-serif、serif或者monospace，这三个是CSS定义的通用字体族（generic family），它们不代表任何具体字体，而是代表一类字体的风格。

浏览器在匹配完所有具体字体名之后，如果都没找到合适的字体，就会选中系统上"风格最接近"的默认字体来兜底。sans-serif对应无衬线字体，Windows大多会落到Arial，macOS会落到Helvetica，Linux发行版一般会落到DejaVu Sans这类；serif对应衬线字体，Windows默认是Times New Roman，macOS是Times；monospace对应等宽字体，Windows是Consolas，macOS是Menlo。

这个兜底字体必须写，原因有两个：第一，你是无法预判每一个访客系统上都装了哪些字体的，别人没装你指定的字体时，至少风格统一的兜底字体还能保住整体视觉；第二，规范的字体栈书写方式本身就要求以通用字体族结尾，这也能帮助你检查自己有没有把字体栈写完整。我见过不少人把字体栈结尾的sans-serif去掉，只留一个不存在的自定义字体名，结果整站文字全部变成浏览器默认的宋体，那种页面观感基本是灾难级的。

2. 中文场景跑得通的font-family字体栈，到底该怎么配

解决了基础机制，接下来是实战配置。这里我不会推荐那种"一个字体栈打天下"的写法，因为纯英文站、中英文混排站、代码展示区对字体的要求完全不同，需要分开设计。

2.1 英文优先的经典字体栈与它的现实局限

先看一段几乎每个人都见过的经典英文字体栈：

font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", Arial, sans-serif;

这套写法就是很多UI框架（比如Bootstrap）的默认方案。它优先用macOS和iOS上的系统字体（-apple-system是Apple私有写法，BlinkMacSystemFont对应Chrome在macOS上的一个历史遗留问题），然后是Windows的Segoe UI，再到Android的Roboto，最后Helvetica Neue、Arial兜底。

这套方案的优点是覆盖了桌面端和移动端几乎所有主流系统，视觉风格统一且性能好，不需要加载任何外部字体文件。但它有一个明显的短板：只适合纯英文或者以英文为主、少量中文点缀的场景。你把这段字体栈放到一个中文网站上，中文部分会一直落到最后的sans-serif兜底字体上，Windows上就是Arial，而Arial的中文字形实际会由系统替换成中易宋体，最终显示效果就是难看的宋体混合Arial。所以中文项目必须在中文字体名上做文章。

2.2 中英文混排时怎么设计字体优先级

中文站点里，正文通常要保证三件事：中文显示为黑体类（无衬线）确保屏幕可读性，英文部分不要被中文字体拖着走，数字和单位不能被显示成奇奇怪怪的样式。对应的字体栈可以这么写：

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

重点看中文部分：macOS/iOS优先用苹方（PingFang SC），这是苹果系统最现代的中文黑体；没有苹方就落到冬青黑体简体中文（Hiragino Sans GB，macOS旧版本自带）；Windows上优先微软雅黑（Microsoft YaHei）；Linux没有上述字体时落到文泉驿微米黑（WenQuanYi Micro Hei）；最后sans-serif兜底。

这样排序的含义是：英文和数字实际上会在前面的Segoe UI、Roboto、Helvetica Neue、Arial里被命中，根本轮不到中文字体处理；中文则按照操作系统的不同做梯度选择。用系统自带字体，不依赖网络加载，这是做企业站、后台管理系统这类对加载速度敏感的项目的首选方案。

2.3 代码区块、数据面板里的等宽字体选择

除了正文，代码、日志、金额、编号这类内容需要等宽字体，因为每个字符宽度一致，能保证对齐，看起来也专业。常用的等宽字体栈是：

code, pre, kbd { font-family: "SF Mono", "Cascadia Code", Consolas, "Liberation Mono", Menlo, Courier, monospace; }

macOS上优先用SF Mono（Xcode自带），Windows 11及以上可以用Cascadia Code，老Windows用Consolas，Linux用Liberation Mono，Menlo是macOS的经典等宽字体，最后monospace兜底。

这里有个经验之谈：像nl、0O、1lI这类容易混淆的字符，好的等宽字体都会做辨识度设计，编程时盯着看半天不累。Cascadia Code还自带连字功能（把=>、!=这类符号渲染成更紧凑的样式），这个对阅读代码体验提升很大，Visual Studio Code里可以直接配置。我一般会在代码高亮主题里把字体栈单独提出来，而不是让代码区继承正文的sans-serif栈。

3. 系统字体差异与本地化适配，跨平台项目的必修课

如果只在自己的电脑上开发，字体栈怎么写都"看着正常"。一旦产品要交付给不同系统的用户，你就必须知道每个系统默认带了哪些字体、哪些看似通用的字体名其实在不同系统上长着不同的脸。

3.1 Windows、macOS、Linux、移动端各自的自带字体清单

Windows这边，XP时代是宋体（SimSun）和黑体（SimHei）的天下，Vista之后微软雅黑成为中文默认字体，Win11又新增了更现代的中文黑体"Microsoft YaHei UI"并预装了Cascadia Code。macOS这边，中文默认字体是苹方，从OS X 10.11开始取代了之前的华文黑体（STHeiti）和华文细黑；旧系统里的冬青黑体（Hiragino Sans GB）现在基本沦为兼容选项。Linux发行版繁多，最常见的中文字体是文泉驿微米黑，部分发行版预装思源黑体（Noto Sans CJK SC）。Android的中文默认字体是思源黑体的一个定制版（对应系统内名为"Noto Sans CJK SC"），iOS则和macOS一样是苹方。

知道这些有什么用？最直接的作用是让你判断某个字体名可不可以作为"系统自带字体"直接写进font-family。有人喜欢把"思源黑体"写进字体栈，但绝大多数Windows用户并没有装这个字体，写了等于白写，只会命中后面的兜底。所以不是越好看的字体越值得写，而是优先写各平台大概率自带的中文字体名。

3.2 直接使用system-ui关键字，省心但有边界

CSS规范里有一个关键字system-ui，它直接指代"当前操作系统的默认UI字体"，在Windows上是Segoe UI，在macOS/iOS上是SF Pro/苹方组合，在Android上是Roboto。写起来非常简洁：

body { font-family: system-ui, sans-serif; }

这套写法的优点是语法标准、兼容性在主流浏览器里已经非常成熟，还能让页面字体跟操作系统UI保持一致，观感很原生。但我实际用下来发现它有几个边界：第一，system-ui在部分浏览器里的实现细节有差异，Safari一些老版本会把它解析成和-apple-system不同的结果；第二，它无法精调中文字体优先级，你在Android上拿到的是Roboto+Noto Sans CJK的组合，在Windows上中文还是落到微软雅黑，想指定某个中文字体优先就得写在它前面；第三，不同平台对system-ui字重（font-weight）的映射不完全一样，容易在按钮、标题上出现粗细不一致。

所以我的建议是：后台系统、工具类站点可以直接用system-ui打底；但对视觉细节要求高的品牌站、内容站，还是老老实实写显式字体栈，把每个平台的字体顺序控制在自己手里。

4. 用@font-face引入自定义字体，不踩这些坑就成功了一大半

系统自带字体再方便，设计上总有它满足不了的时候。品牌字体、特殊标题字、图标字体，都得靠@font-face把字体文件加载到页面里。这块的水比想象中深，文件格式、兼容策略、加载性能、乱码问题，每个环节都有人翻车。

4.1 字体文件格式怎么选：woff2优先，别贪多

@font-face声明要包含来源字体文件路径、自定义字体名和字体格式。现代前端标准里我们主要关注两种格式：WOFF2和WOFF，它们都是专门为web设计的压缩格式，其中WOFF2基于Brotli压缩，体积通常只有WOFF的三分之二左右，是目前所有主流浏览器都支持的格式。至于老掉牙的EOT（IE专用）和SVG字体，除非你要兼容IE6-8这种远古环境，否则完全没必要引入。

我推荐的最小声明只保留WOFF2和WOFF：

@font-face { font-family: "MyBrandFont"; src: url("myfont.woff2") format("woff2"), url("myfont.woff") format("woff"); font-weight: 400; font-style: normal; font-display: swap; }

这里有几个细节必须强调：font-family里起的名字是为了在页面其他地方引用，可以随便取，但同一个字体家族不同字重的声明，font-family必须保持一致，靠font-weight区分。如果你对400和700分别写两个不同名字的@font-face，然后页面里用font-weight: bold，浏览器是找不到700字体的，会直接给你伪造加粗（后面细说）。另外，src里的字体文件路径如果是相对路径，要确认相对于CSS文件而不是HTML文件，很多人刚用构建工具时在这里栽过跟头。

4.2 font-display、预加载与子集化，一个都不能少

自定义字体最大的代价是性能。浏览器在字体文件加载完成之前，会先按照 fallback 策略用备选字体渲染文字，等字体就绪后再突然切换，这个现象叫FOUT（Flash of Unstyled Text）或FOIT（Flash of Invisible Text）。font-display: swap就是为了解决这个问题——它告诉浏览器：字体没加载完就先显示兜底字体，别让文字不可见。对中文网站来说，建议正文用swap，因为中文用户对文字突然出现已经非常敏感；对英文Logo、品牌数字这类可以接受短暂"隐形"的元素，也可以用font-display: block，避免加载过程中用户看到丑陋的兜底字形。

性能优化还有两步：第一步是preload关键字体。在HTML的head里加<link rel="preload" href="myfont.woff2" as="font" type="font/woff2" crossorigin>，让浏览器在解析到CSS之前就提前下载字体文件，可以把首屏字体就绪时间提前几百毫秒。第二步是子集化（subsetting）。中文字体动辄几MB，因为全量字符集太大了，web场景必须把字体文件裁剪成只包含页面会用到的那些字符。现在很多构建工具都有字体子集化插件，也可以直接用一些在线工具切出"基本拉丁+常用中文3000字"的子集，体积能缩小到原来的十分之一。再加一个unicode-range按Unicode区块去声明字体适用范围，浏览器就能在真正遇到对应字符时才去请求字体文件，这是中文字体性能优化里最值钱的一招。

5. 和font-family配合使用的字体属性，细节决定成败

把font-family写对只是第一步。一个页面字体的最终呈现效果，还取决于字号、行高、字重、字间距这些属性之间的配合。很多"字体效果奇怪"的问题，其实是这些配套属性的锅。

5.1 font-size与line-height对中文字体的特殊影响

中文字体跟英文字体的字号感知完全不同。英文小写字母占的高度小，大写字母和上下伸部占的空间大，所以同一份line-height下英文看起来还挺协调；中文每个字都是方块字，占满整个em框，在相同字号和line-height下，中文的视觉密度明显比英文高。这就是为什么老手做中英文混排时会分别设置行高：英文段落给1.5-1.6，中文段落往往要给1.7-1.8甚至更高，不然中文一行一行挤在一起，读起来喘不过气。

这里还有个常见误区：line-height的数值写好之后，要不要随着font-size一起写进font简写属性里？font简写的语法是font: font-style font-weight font-size/line-height font-family;，比如font: normal 400 16px/1.8 "PingFang SC", sans-serif;。注意简写属性如果不写font-family，会导致字体设置被重置成初始值，这在写组件样式时特别容易埋雷。我通常的做法是：全局基础样式里用font简写一次，后续组件单独微调用font-family或font-size覆盖。

5.2 font-weight的伪粗体问题，别让浏览器帮你"造假"

网页里设置font-weight: bold时，如果当前字体家族没有真正的粗体字形，浏览器可能会做两件事：要么用算法把常规字形加粗（合成粗体），要么在多个字重之间做插值。合成的粗体在屏幕上看就是笔画糊成一团，尤其Windows下的宋体、雅黑在部分场景下特别明显，中文笔画的撇捺一加粗就黏连。

真正的解决方案是保证字体栈里包含你需要的字重。system字体里的思源黑体、苹方其实都内置了多个字重，只要你在CSS里正确声明font-weight: 400、font-weight: 500、font-weight: 700，浏览器就会去拿对应的真字重文件，而不是伪造。用@font-face加载自定义字体时，更要严格把每个字重单独声明，不要图省事只加载一个regular，然后在页面里强上font-weight: bold，那样出来的效果我保证你不会想交付给客户。

另外顺带提一个经常被忽略的点：macOS和Windows对字重渲染的偏差。苹方字重偏细，同为400的字重，在macOS上看很舒服，切到Windows上Segoe UI的400明显更粗。同一份设计稿两侧显示效果不一样是正常的，设计评审时不要为这种事纠结太久，这是跨平台渲染特性，不是代码bug。

6. 字体没生效？按这条链路排查，十分钟定位问题

最后聊最实用的部分：当页面文字没有按你预期的字体渲染时，怎么排查。我见过太多人在论坛里发"我写了font-family但它不生效"，截图里的代码五花八门，但原因翻来覆去就那么几类。

6.1 从"看着不对"到锁定根因的四步排查法

第一步，确认CSS选择器真的命中目标元素。用浏览器开发者工具的Inspect功能选中文字，看Computed面板里的font-family到底是什么。如果显示的是浏览器默认值，说明你的样式被覆盖了，优先检查选择器优先级和样式加载顺序，后加载的同优先级样式会覆盖先加载的。

第二步，确认字体名拼写无误且目标系统上确实装了。字体名字符串一个字母都不能差，"PingFang SC"写成了"PingFangSC"就匹配不上。在别人的电脑上不生效，优先怀疑字体缺失，可以开一个系统字体面板对比确认。

第三步，确认字体文件真的加载成功。用@font-face的场景，打开Network面板看字体文件请求是不是200，有没有404、CORS报错。字体文件跨域请求必须服务端返回正确的CORS头，本地开发时尤其常见这个问题。另外确认font-display没有设置成会隐藏文字的取值，长时间不显示可能不是字体没生效，而是FOIT行为。

第四步，确认没有其他CSS属性干扰。text-transform、font-variant、-webkit-font-smoothing这些属性都会影响字形最终呈现，-webkit-font-smoothing: antialiased在macOS上会让字体变细，Windows上无效；text-rendering: optimizeLegibility对部分字体的连字和间距也有影响。把这些属性逐个关掉对比，就能定位是谁在捣乱。别小看这步，我遇到过一整个页面字体总是发虚，最后发现是-webkit-font-smoothing在作祟。

6.2 开发者工具里的字体可视化检查，比睁眼猜高效得多

Chrome开发者工具的Rendering面板里有一个"Highlight all text"选项，开启后页面上每一段渲染文字都会被高亮框出来，同时Elements面板的Computed选项卡会显示实际生效的字体名。Safari的Web Inspector里也有类似的字体检查能力，Firefox的Fonts面板更是直接列出了当前元素用到的所有字体文件。

排查字体问题时我的固定动作是：先用Computed面板确认font-family解析结果，再用Rendering面板高亮看哪些文字用的是预期字体、哪些用了兜底字体，基本一眼就能锁定问题范围。如果是中英文混排问题，把高亮的文字放大看，一般问题就是英文落到了中文字体上，或者中文字体名没匹配上。这种可视化手段特别适合排查那种"80%的文字正常，个别字符异常"的疑难杂症。

实际项目里还有一招很有用：临时往字体栈最前面插入一个你确定系统里存在的自定义字体名，比如"Comic Sans MS"，如果文字变成了Comic Sans MS，说明你的字体栈机制本身没问题，纯粹是想要的那个字体没生效；如果文字纹丝不动，说明整个font-family声明被覆盖或语法有问题。这个"探针字体"法帮我在几分钟里分清了很多次"字体栈问题"和"字体缺失问题"。

最后分享一个我自己的习惯：给每个项目都建一份font.css，把正文、标题、代码、数字的字体栈统一收拢，加上异体字、字重、行高、-webkit-font-smoothing这类全局配置，写清楚注释。新页面需要字体时直接复用，不重复在业务样式里写散落的font-family。项目跑了一段时间后再回看这份文件，会发现它既是一份字体配置，也是一份全站文字排版规范的活文档，比翻历史代码猜当初为什么这么写要省事得多。