企业官网建设流程全解析

1. 一个 font-family 连招，凭什么决定整个页面的颜值

只要你写过前端页面，大概率听过一句话：HTML负责骨架，CSS负责颜值。可真正把页面做完，打开浏览器一看，标题字又方又愣，正文却像旧报纸，中英文混排更是各说各话。朋友过来扫一眼，点评一句：“你这页面，像用文本文档另存了个网页吧。”这个场景我见过太多次，而且绝大多数时候，元凶根本不是配色，也不是间距，就是CSS里那几行字体设置。

严格来说，字体并不是HTML标签直接管的，写style属性也好，写class也罢，真正生效的都是font-family。但前端萌新不会背这口锅，因为页面丑的第一感知，确实会落在HTML结构上。今天这篇不绕弯子，直接把我处理过的字体问题拎出来说透：浏览器怎么挑字体、字体栈顺序为什么会影响颜值、我自己踩过的几个大坑，以及可以直接抄走用的模板和检查清单。

1.1 浏览器挑字体：它是按字符捡漏，不是按标签排队

font-family写多个字体的时候，浏览器做的事情，并不是把一条规则整套套在元素上，而是对每个字符单独去“捡漏”：先看第一个字体有没有这个字形，有就立即使用，没有就跳到第二个，一直跳到最后。这个机制很多人天天在用，却从没意识到它才是各种字体乱象的总根源——因为你在页面上看到的中文和英文，很可能分别来自两个完全不同的字体，甚至同一个句子里的字符都能被拆开派给不同字体。

我最早接手某企业官网时，以为把最好看的字体放在第一个就行了，结果页面上所有中文都变成了默认宋体。原因很简单：排在第一的字体是西文字体，里面根本没有汉字字形，浏览器并不会因为第一个字体“配不上”这行字就直接换一整套路，它会按字符老老实实继续找，直到找到第一个能显示汉字的字体。如果不做任何指定，最后掉到系统默认宋体太正常了。

举个最直接的例子：font-family: "Times New Roman", "微软雅黑", sans-serif;在这个设置下，汉字会显示成微软雅黑，但英文和数字全部是Times New Roman。效果就是标题里“Hello 世界”五个字符被劈成两个世界：Hello是带衬线的老式印刷风格，世界却是现代黑体。放在一起，视觉上就像西装领带配了双运动鞋，单看哪边都不丑，合在一起就是别扭。前端新人经常会觉得“我明明设置了字体，为什么中英文不统一”，其实背后的原理就在这一层字符级回退机制里。

1.2 顺序一换，脸就变：中英文混排的踩点

正因为浏览器按字符回退，字体顺序就直接决定了中英文混排的气质。同一个短句，把字体顺序换一下，效果完全不同。比如font-family: "微软雅黑", "Times New Roman", sans-serif;这样写，英文和数字会优先使用微软雅黑自带的拉丁字形，风格倒是和中文字形统一了，但仔细看就是差一口气：微软雅黑里的拉丁字母、数字，在笔画比例、字怀大小、数字高度这些细节上，和专门设计的西文字体放在一起对比，精致感会明显下降。

反过来，把Times放前面，又会出现衬线英文配黑体中文的冲突。所以实际项目里的正确姿势，通常是把要主打的西文字体放前面，中文黑体放后面，让英文数字用西文，中文汉字用黑体，各回各家。你可以用下面这个表快速理解不同顺序带来的观感差异：

可见，字体栈从来不是“选一个我最喜欢的字体”就够了，而是要给不同字符分别做选择。为什么很多设计稿到了开发手里会变丑？一个很常见的原因就是设计稿里指定了英文字体和备用中文字体，开发却把它俩写反了，或者干脆只写了中文字体，英文数字全部退回中文字体自带拉丁字形。

1.3 不写字体栈的时候，系统在背后替你选了谁

很多萌新拿到的第一个页面，最丑的时候往往是没有写任何字体CSS的裸HTML。这时候浏览器不会找不到字体，它一定会用操作系统或浏览器设置的默认字体来渲染。在Windows系统的老版本浏览器里，中文可能落到宋体，英文可能是Times New Roman；换到macOS，中文又变成苹方，英文变成Helvetica一类的无衬线字体。同一个页面，在自己电脑上看着还行，换到别的电脑立刻变味儿，字体就是最大的变量之一。

宋体搭配Times这套组合，放在屏幕上是典型的旧式文档感。并不是它不好，而是它和现代网页UI放在一起不太匹配。你想要的“现代感”“高级感”，在字体层面往往就是黑体系字体加无衬线西文带来的。很多页面改版时什么都不动，只把全局字体从宋体改成系统黑体栈，再顺手调一下行高，整个气质就能完全不同。这个投入产出比，比反复调颜色高得多。

2. 别一套字体走天下：正文、标题、代码要分开配

看到很多站点，全局一个font-family用到底，所有文本都长一个样。我不是说不行，而是你根本没有利用字体之间的反差去建立视觉层级。做一个页面，正文、标题、代码是三种完全不同的阅读需求，给它们配同一套字体，等于让一个人同时干三份完全不沾边的活儿，效果自然打折扣。

2.1 为什么正文和标题不能共用一套

标题适合黑体系无衬线字体，笔画均匀、字怀大，放大之后不散架；正文在屏幕上也是无衬线更容易阅读。宋体这类衬线字体，笔画末端有装饰，粗细对比强，更适合报纸、书籍、论文这类连续长文。在低分辨率屏幕上，小字号宋体的笔画边缘容易发虚，长时间阅读反而更累。所以大多数网页正文默认走黑体系是合理选择。

我的习惯是：正文用一个考虑中英文混排的系统字体栈，标题单独给一套更有性格的字体，可以是同一字体的加粗，也可以是带衬线的Georgia或者宋体系。比如把文章引用块、章节大标题设成Georgia搭配宋体，会立刻有杂志感，而正文保持现代无衬线，整个页面的层次一下就出来了。要记住，字体选择不是给自己看的，是给用户的阅读节奏看的。

2.2 中文和西文的排列原则：确定主线，再放中文字体

之前说过，中文字体自带拉丁字形，但自带不等于好。把Arial这类西文字体放前面，中文字体放后面，实际含义是：英文数字请优先使用这套西文，如果字符是中文，再按顺序找到中文那一家。这样处理以后，英文数字能用到更专业的字形，中文也能稳定显示，组合起来才协调。

以一套常见的黑体栈为例：font-family: Arial, "PingFang SC", "Hiragino Sans GB", "Microsoft YaHei", sans-serif;Arial里没有中文字形，所以中文会自动落到苹方或雅黑；英文数字则留在Arial里。注意，黑体栈对应的通用族是sans-serif，不要写成serif，否则前面几个字体都缺失时，系统会给你配一套衬线字体兜底，风格直接跑偏。

如果页面是偏正式、偏文档风格的，主线可以换成衬线组合：font-family: Georgia, "Times New Roman", "Songti SC", "SimSun", serif;。这种情况下，中文用宋体系，英文用衬线体系，整体气质一致。这个原则我总结成一句话：先定视觉主线，主线上对应的西文字体放最前面，同名风格的中文字体放后面，最后用通用族收尾。

2.3 代码和数字的特殊要求

代码字体必须是等宽字体，这不是审美问题，是功能问题。等宽字体保证字母I、l、数字1、0在水平方向的宽度一致，代码看起来才对得齐。正文里可以接受Arial这种比例字体，但代码区一定要单独指定。像font-family: Menlo, Consolas, "Courier New", monospace;这种栈，就能保证Windows和macOS上都有一套像样的等宽字体兜底。

数字对齐是另一个经常被忽略的需求。你做一个数据面板，数字从1变成10，如果字体默认使用比例数字，整列宽度就会左右乱跳。解决方案是给数字区域设置font-variant-numeric: tabular-nums;，或者兼容性更保守的font-feature-settings: "tnum";，让字体启用等宽数字特性。不是所有字体都支持这个特性，设置完一定要在目标浏览器里实测一遍。

3. 我踩过的四个字体坑：从现象到根因的完整链路

这一节我不直接给结论，把当初怎么排查的过程也一并写出来。字体问题之所以坑，就是因为它不报错、不崩溃，只是静默变丑，不按排查链路走，你很容易在错误方向上消耗大半天。

3.1 引号坑：全角引号让整条font-family失效

第一个坑特别蠢，但也特别常见。从某份文档里复制现成的CSS片段，看到font-family: “微软雅黑”, Arial, sans-serif;时，很多人看不出问题。但注意，这段代码里的引号是中文全角引号，不是英文半角引号。CSS解析器根本不认全角引号，它不是一个合法的字符串定界符，于是整条font-family声明会被浏览器当成无效声明直接丢弃。

现象就是你在编辑器里明明写了样式，运行时却完全没生效，中文回到默认宋体，英文也变成奇奇怪怪的系统默认。排查链路是这样的：打开浏览器开发者工具的Computed面板，选中异常文字，发现最终生效的font-family压根不是自己写的；再回到Sources里看原始字符串，才发现引号是全角。修复很简单，统一改成英文半角引号，或者干脆把带空格的字体名用引号包好，不带空格的字体名可以不写引号。

这个坑在网上提问区几乎每周都能看到。遇到样式莫名其妙全线失效，第一反应不应该是怀疑缓存，而是先检查引号、分号、拼写。尤其是多人协作项目，从文档、聊天记录、代码片段站复制代码时特别容易带进来脏字符。

3.2 只写了一个平台字体，整个渲染直接翻车

某次给一个跨平台页面配字体，我只写了font-family: "微软雅黑", sans-serif;，在Windows上非常正常，但朋友用macOS打开之后，页面文字没有按预期掉到苹方，反而落到一个很陌生的楷体系列里。原因是macOS上根本没有微软雅黑这种字体，按字符回退逻辑跳到了sans-serif，系统再基于本地可用字体给出一个默认值，效果自然和Windows天差地别。

这种问题的可怕之处在于它完全不报错。CSS的设计就是“没有就用下一个”，所以浏览器不会给你任何警告。排查方法我建议学会控制台这行命令：document.fonts.check('16px "微软雅黑"')。返回true表示当前环境确实能提供这个字体，返回false就说明当前设备上没有它。设计阶段在目标系统上跑一次，比上线后收到用户截图再修要快得多。

后来我把字体栈改成了多平台通用方案：苹方、雅黑、思源黑体依次排开，最后sans-serif收尾。顺序也不是随意排的，要看目标用户用什么系统、屏幕是什么形态。但无论如何，兜底一定得有，否则你就是在猜用户电脑里有什么字体。

3.3 Web Font加载坑：中文字体动辄几十兆，白屏能让人等睡着

为了追求某个特定标题字体，我干过一件特别傻的事：直接把一个完整中文字库引入页面。woff2文件加载起来几兆甚至几十兆，首屏在最上面卡住好几秒，用户看到的就是一片白。这是中文Web Font的本质难题——常用汉字几千个，全量字库必然很大，而做网页又不能只放一两个字符。

我的修复思路分两步：能不用就不用；非要用就做子集化。子集化就是把页面中真正出现过的文字提取出来，生成一个只包含这些字的子集字体，通常能压到几十KB。具体用在线工具还是命令行脚本都行，原理都一样：解析文本、保留需要的字形、重新打包成woff2。同时给@font-face加上font-display: swap;，让文字先用兜底字体渲染，字体文件加载完再切换，避免长时间白屏。

如果字体只用在标题上，还可以配合媒体查询或者按需触发加载，而不是在首屏把所有资源全部请求一遍。很多优化手段本身不复杂，只是萌新不知道中文字体原来这么大，一上来就把全量字体塞进项目，性能自然崩。

3.4 数字跳动坑：数据列表充满动感，但我并不想要

第四个坑来自一个统计数据面板。数字从1变成10，整列数字的宽度肉眼可见地抖。一开始我以为是动画问题，排查了半天才发现是字体里的数字特性在作怪。大多数西文字体默认使用比例数字，4和1宽度不一样，10比1宽出一截。列表一刷新，数字宽度变化，列就会左右跳。

解决方式不复杂，给数字容器加font-variant-numeric: tabular-nums;，或者用兼容性写法font-feature-settings: 'tnum';，浏览器会尽量使用字体内部的等宽数字形态。如果当前字体不支持这个特性，那就只能换一种支持等宽数字的字体，或者对数字区域单独指定等宽字体来解决问题。

这个坑提醒我一件事：字体不只是“选好看”，很多细节是由字体特性控制的。选择字体时要想清楚使用场景，数字频繁更新的场景尤其要注意对齐。做数据可视化、后台管理系统、收银台界面时，先把这一条写进技术方案里，后续能少改不少代码。

3.5 四个坑的快速对照表

把上面四个坑汇总成一张表，平时自查的时候直接对照：

这四件事不需要很高深的技术就能避免，但只要你没意识到，它们就会在最意想不到的时候冒出来，让你的页面“看起来有点怪”。现在每次在群里看到有人发“为什么我的样式没生效”，我脑子里跳出来的检查表第一行永远是这四件事。

4. 可以直接抄的字体栈和上线前检查清单

原理讲再多，不如给几套能直接落地的配置。下面这三套是我在不同类型项目里长期使用的模板，你可以在此基础上按业务场景调整。

4.1 三套通用字体栈模板

第一套，通用后台和中英文混排UI，重点照顾屏幕阅读和跨平台一致性：

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

顺序里西文在前，中文按苹果、Windows、开源黑体逐级补位。这套几乎适用所有PC端管理后台。

第二套，正式文档、杂志感页面，适合长文阅读和品牌感强的页面：

body { font-family: Georgia, "Times New Roman", "Songti SC", "SimSun", serif; }

Georgia负责英文的衬线气质，宋体系负责中文，整体会比较典雅。注意这种栈在大字号标题上的表现会比正文更好看，正文小字时需要实测确认可读性。

第三套，代码展示或数据面板：

code, pre { font-family: Menlo, Consolas, "Courier New", monospace; }

等宽字体保证字符对齐。如果项目里有特殊代码字体需求，也一定要保持最后一个是monospace，否则用户字体不够时，浏览器会给你配一个完全没对齐概念的默认字体。

这里要特别强调：通用族一定要写在最后。不要懒到只写一个sans-serif完事，虽然浏览器会兜底，但具体字体由系统决定，在不同设备上表现会非常随机。写了通用族，至少视觉方向不会跑偏。

4.2 字体栈排错链路

如果已经发现字体出了问题，按下面顺序排查，应该能覆盖九成情况。首先打开浏览器开发者工具的Computed面板，选中异常文字，看最终生效的font-family到底是什么。如果和CSS里写的不一致，说明有更高优先级的规则覆盖了你的声明，或者声明本身已经被丢弃了。

其次，在控制台跑document.fonts.check，确认目标字体在当前设备是否存在。很多萌新会忽略这一步，以为字体名写对了就一定存在，实际上不同操作系统、不同浏览器能提供的字体集合差异很大。接着检查继承关系，看看是不是有某个统配选择器写了* { font-family: ... }，这种覆盖在引入第三方样式库时特别常见。

最后才是语法检查：引号是否是半角、有没有漏分号、字体名之间逗号是否完整。全部查完如果还没解决，就做一个“只保留一条字体”的对比，逐步删掉字体栈里的候选字体，定位到底哪个字体名导致回退异常。这个方法最笨，但最能解决问题。

4.3 上线前十分钟自查清单

我习惯在发布之前用固定表快速过一遍，字体相关部分长这样：

这张表不解决审美问题，但能挡住八成“丑得莫名其妙”的情况。审美可以慢慢培养，因为这些低级原因被扣上“前端不行”的帽子，实在有点冤。

5. 中文站点到底要不要用 Web Font：我的取舍标准

很多人一开始觉得Web Font是解药，用了就能彻底摆脱系统字体差异。但在中文网站上，事情远没有这么简单。

5.1 明白中文Web Font为什么“贵”

英文Web Font比较轻，因为字母加数字也就两百个字符左右。中文常用汉字光GB2312就有几千个，不是设计师想偷懒，而是字形数据实打实占空间。一个包含常用汉字、多字重的中文字体，全量打包下来肯定能到几兆甚至十几兆，这对网页来说是不可忽视的加载成本。

所以遇到业务需求说“标题要用某某艺术字体”的时候，我一般先追问：到底会用到哪些字？如果只是品牌名、固定文案里的十几个字，做子集化完全可行，加载成本可以忽略不计。如果是用户动态输入的内容，那就没法预判要覆盖哪些汉字，只能用系统字体栈，或者做好大体积字体文件缓存策略。

5.2 font-display与预加载的实操

当确定要使用Web Font，至少要做两件事：设置font-display，以及按需preload。font-display有auto、block、swap、fallback、optional几个档位。网页里最常用的是swap：先显示回退字体，字体文件就绪后再替换，视觉上不会出现长时间白屏；optional则更激进，弱网环境下一旦字体没能在极短时间内加载完，就直接放弃，用回退字体渲染整页。

代码长这样：

@font-face { font-family: "MyTitle"; src: url("/fonts/my-title.woff2") format("woff2"); font-display: swap; }

preload不要乱用。只把最关键、而且确实要马上使用的字体子集加上preload，其他字体正常加载就好。否则一堆preload同时抢带宽，反而会拖慢首屏。我在一个项目里试过给三个字体文件都加了preload，结果首屏时间反而变慢了，去掉两个之后速度立刻恢复正常。

5.3 我自己的取舍标准

经验少的时候，我总想着把最好看的字体塞进页面。被朋友吐槽过几次，也连续好几个版本被业务方打回之后，我逐渐变成实用主义者。现在的标准很简单：正文和界面主体，无条件优先用系统字体栈；品牌标题、固定文案这种东西，可以上Web Font但必须子集化；长文阅读场景，优先保证字重和行高配置，而不是追求艺术字体。

任何一次评审，如果字体带来的视觉收益大于加载成本，才值得做。反过来说，把精力放在间距、字重、行高、段落宽度这些排版细节上，页面颜值提升往往更明显。字体本身只是基础，真正拉开差距的是使用方式。

最后分享一个我坚持了很多年的习惯：新项目开工第一天，就把第4节的模板贴进全局样式，然后约定，没有特殊情况不允许团队随处另开一套字体。字体选择一旦“百花齐放”，页面就会像多国部队会师一样混乱。风格统一比任何单个字体的好看都重要，这个原则帮我救回过不少临时加入的页面，也让我自己少吵了很多架。