企业官网建设流程全解析

1. 网站中文字体替换，到底难在哪里

如果你做网站开发超过一两年，大概率绕不过这个坎：中文字体实在太大了。西文字体一个文件几百KB已经算大的，中文字体随便一个完整字库就是几MB甚至十几MB。我见过不少个人博客，因为直接挂了一个完整版思源宋体，首屏加载直接多出8MB的流量，移动端打开卡得用户直接关页面。所以“换中文字体”这件事，从来不是“把字体文件丢进CSS里”这么简单，它牵扯到加载策略、格式兼容、渲染性能、版权合规，甚至还有你到底该走CDN还是该把文件放到自己服务器上的路线选择。

这篇文章我会把两条路线都完整走一遍：一条是通过CDN引入，一条是直接引入（也就是把字体文件放在自己站点目录下，通过@font-face声明加载）。我会结合自己实际做过的几个项目，把两条路的优缺点、适用场景、具体配置、还有那些文档里不会写的坑都讲清楚。

适合谁来读？如果你是个人博客站长、前端开发、独立开发者，想给网站换一套好看的中文字体，又担心影响性能和兼容性，这篇文章可以直接当参考手册用。我尽量用大白话讲原理，同时给出可以直接抄的配置代码。

先说结论：两条路没有绝对的好坏。CDN引入最省事，但可控性和国内访问速度经常出问题；直接引入前期麻烦一点，但一旦配置好，稳定性和性能反而更好。接下来我按技术细节慢慢拆。

2. 方案的底层逻辑：字体格式、加载策略与两种引入方式的本质区别

2.1 中文字体为什么这么大，格式怎么选

在聊引入方式之前，得先把字体本身的“物理特性”搞清楚。一个中文字体文件动辄好几MB，是因为常用汉字就有三千多个，加上标点、生僻字、扩展字集，字形轮廓数据量自然就上去了。英文26个字母加上数字符号也就一百多个字形，跟中文完全不是一个量级。

所以做中文字体替换，第一件事就是格式选型。目前Web端主流的字体格式有这几种：

• TTF（TrueType）：最通用的格式，Windows、macOS、Linux都能直接安装，浏览器支持也比较完整，但体积大，压缩率低。
• OTF（OpenType）：可以包含PostScript轮廓，某些特殊字体的高级排版特性更好，但Web端兼容性和TTF差别不大，体积也大。
• WOFF：专门为Web设计的格式，本质是TTF/OTF加压缩，体积明显缩小，IE9+、Chrome、Firefox等主流浏览器都支持。
• WOFF2：WOFF的升级版，采用Brotli压缩，体积比WOFF再小30%到50%，目前除了老掉牙的浏览器，几乎全线支持。

我的建议很简单：能用WOFF2就用WOFF2，并准备一个WOFF或TTF做老浏览器回退。如果你从某处下载的字体是TTF格式，直接丢到网站上也能用，但不推荐——同样的字体，TTF可能5MB，转成WOFF2后可能只有2MB多，这差距对网页加载是致命的。

提示：字体格式转换可以用fonttools（Python库）或者在线工具，比如 transfonter.org、fontsquirrel.com 的 webfont generator。我个人更推荐本地用 fonttools，因为在线工具偶尔会破坏字体内部的排版信息，尤其是处理一些商业字体时。

2.2 CDN引入和直接引入的本质差异

表面上，CDN引入和直接引入只是字体文件存放位置不同，但实际影响面很广。

CDN引入的本质是“走别人的服务器资源、借别人的带宽分发”。引入方式通常有两种：一种是用现成的公共字体CDN服务，比如 Google Fonts、jsDelivr 上别人打包好的字体仓库；另一种是你自己把字体传到 GitHub、又拍云、七牛云等对象存储，然后通过CDN加速域名对外分发。无论哪种，字体文件都不在你的网站服务器上。

直接引入的本质是“自托管”，字体文件放在你的网站目录下，和图片、CSS、JS一样，由你的服务器或你当前使用的托管平台（比如 Vercel、Netlify、GitHub Pages）直接吐给用户。

这两者有几个层面的差异：

你可能会问，既然直接引入这么可控，为什么还有那么多人在用CDN？因为省事。对于个人博客、内容站，或者你只是临时换个字体看看效果，CDN引入简直是解放劳动力。但一旦涉及到性能优化精细化控制、商业项目授权、或者国内用户特别多的情况，直接引入几乎必然胜出。

2.3 渲染机制：为什么换字体时页面会闪一下

这里必须补一个几乎所有教程都会忽略的点——字体的加载和渲染机制。浏览器遇到CSS里声明的font-family时，并不会立刻下载对应的字体文件，而是先按当前系统默认字体渲染文字，等字体文件下载完成后，再“偷偷”替换成目标字体。这就引发了两种常见现象：

• FOIT（Flash of Invisible Text）：浏览器在字体下载完成前，直接把文字隐藏，下载完了才显示。用户会看到一片空白，体验极差。
• FOUT（Flash of Unstyled Text）：浏览器先用回退字体渲染，字体到位后再切换。用户会看到字体“闪变”，但至少内容是可见的。

早期浏览器默认行为是FOIT，现在已经普遍支持font-display属性来控制。font-display: swap是最常用的策略，它告诉浏览器：“先别藏文字，用备用字体显示，等我下载完再换。”对中文网站来说，swap几乎是必选项，因为如果不加，用户可能在慢网络下盯着白屏好几秒。

后面讲具体操作时，我会在CSS里把font-display一起给你写清楚。这一点如果你直接抄网上老代码，很容易漏掉。

3. 直接引入中文字体的完整实操流程

3.1 获取字体文件与格式转换

先讲直接引入，毕竟它更通用。第一步是拿到字体文件。如果你有设计团队提供的正版字体授权文件，直接用；如果是个人项目，我通常优先推荐思源黑体（Source Han Sans）和思源宋体（Source Han Serif），这两款是Adobe和Google联合开源的，SIL Open Font License授权，商用完全没问题。另外还有阿里巴巴普惠体、得意黑等，都是开源且质量不错的国产中文字体。

拿到TTF/OTF后，我建议立刻转一份WOFF2。这里给出用fonttools转换的命令行方法：

# 安装fonttools，如果已经装过可以跳过 pip install fonttools brotli # 将OTF/TTF转换为WOFF2 fonttools ttLib.woff2 compress SourceHanSansCN-Regular.otf -o SourceHanSansCN-Regular.woff2

注意，这里的brotli库是必须装的，不然WOFF2压缩会报错。如果字体文件是OTF格式，转出来没问题；如果源文件本身就特别大（比如超过10MB的完整字库），你可以考虑在转换前先做一步“子集化”，这个我放在后面性能优化部分专门讲。

3.2 放置字体文件与@font-face配置

转换完成后，在项目里建一个fonts目录，把字体放进去。比如：

project/ ├── fonts/ │ ├── SourceHanSansCN-Regular.woff2 │ └── SourceHanSansCN-Regular.ttf ├── css/ │ └── style.css └── index.html

然后在CSS里用@font-face声明字体。这里有一个特别容易踩的坑：src顺序不能乱。

@font-face { font-family: 'SourceHanSansCN'; src: url('../fonts/SourceHanSansCN-Regular.woff2') format('woff2'), url('../fonts/SourceHanSansCN-Regular.ttf') format('truetype'); font-weight: 400; font-style: normal; font-display: swap; }

为什么顺序重要？因为浏览器会用“第一个它认识的格式”，然后停止解析后面的。现代浏览器优先认WOFF2，所以把WOFF2放第一个，老浏览器不认WOFF2时，才会继续看后面的TTF。如果你把TTF放前面，那么所有浏览器都会下载TTF，WOFF2的压缩优势就白白浪费了。

光有@font-face还不够，还得把字体“用起来”。在body或者你想换字体的容器元素上设置font-family：

body { font-family: 'SourceHanSansCN', -apple-system, 'PingFang SC', 'Microsoft YaHei', sans-serif; }

这里注意，font-family是优先级列表：如果SourceHanSansCN加载失败，浏览器会回退到系统自带的苹方、微软雅黑等。这个回退机制非常重要，千万不能只写一个字体名，不然字体出问题时整个页面会变成浏览器默认的丑字，连系统字体都轮不上。

3.3 多字重引入：不要一股脑全上

中文网站换字体时，很多人会犯一个“礼貌性错误”：把字体所有的字重都引入，比如Regular、Medium、Bold、Light，甚至Black，然后到处用。结果就是，用户打开你的网站，要下载四五个字体文件，每个2MB起步，首屏数据直接爆炸。

我的建议是，普通内容站最多引两个字重：Regular（400）和Bold（700）。如果设计稿里有Small标题，不妨用Bold配合font-size和letter-spacing来弥补。如果你非要Light或者Medium，那就只在你特别需要的地方用，并且单独做子集化。

多字重的@font-face写法是这样的，每个字重单独一个块：

@font-face { font-family: 'MyFont'; src: url('../fonts/MyFont-Regular.woff2') format('woff2'); font-weight: 400; font-display: swap; } @font-face { font-family: 'MyFont'; src: url('../fonts/MyFont-Bold.woff2') format('woff2'); font-weight: 700; font-display: swap; }

注意，两个块必须用同一个font-family名字，靠font-weight区分。如果你在HTML里写<strong>或者CSS里写font-weight: 700，浏览器就会自动去匹配Bold那个文件。如果用不同的font-family名，那跟直接换一种字体没什么两样，还会增加CSS维护成本。

4. 通过CDN引入中文字体的操作与选型指南

4.1 公共字体CDN的使用方法

CDN引入最典型的例子是Google Fonts。中文场景下，Google Fonts收录了不少开源中文字体，比如Noto Sans SC（思源黑体的Google版）、Noto Serif SC（思源宋体）。接入方式非常简单，在HTML的<head>里加一行<link>标签：

<link rel="preconnect" href="https://fonts.googleapis.com"> <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin> <link href="https://fonts.googleapis.com/css2?family=Noto+Sans+SC:wght@400;500;700&display=swap" rel="stylesheet">

然后CSS里直接用：

body { font-family: 'Noto Sans SC', 'PingFang SC', 'Microsoft YaHei', sans-serif; }

这里有两个小细节。preconnect是告诉浏览器提前建立与该域名的连接，能省下DNS解析和TCP握手的时间。第二行的crossorigin是必需的，因为字体请求是跨域请求，建立连接时就要带上跨域属性。

不过请注意，Google Fonts在国内的访问速度并不稳定。如果你面向的主要用户在国内，直接挂Google Fonts几乎等于放弃了一部分用户的页面速度。我实测过，部分地区访问Google Fonts域名会出现几秒超时，字体一直不加载，页面始终用回退字体渲染，FOUT现象严重。

相比之下，国内有一些公共CDN镜像或者第三方字体托管平台，比如某些开源镜像站、又拍云旗下的字体CDN服务。具体选择哪种，我的建议是：小流量个人项目，优先找国内访问稳定的公共资源；如果是商业项目或者流量上来之后，尽快迁移到自托管，省得受制于人。

4.2 私有CDN分发：从GitHub到对象存储

如果你不想用公共字体库，而是想把自己选好的字体文件通过CDN链路加载，最轻量的做法是利用GitHub仓库加CDN加速。比如你把字体文件推到GitHub仓库里，然后用jsDelivr的GitHub加速功能生成稳定链接。jsDelivr会在全球节点缓存文件，国内访问速度总体还行，但高峰期偶尔也会抽风。

链接的通用格式是：

https://cdn.jsdelivr.net/gh/用户名/仓库名@版本号/字体文件路径

比如：

<link rel="stylesheet" href="https://cdn.jsdelivr.net/gh/yourname/webfonts@1.0/fonts.css">

或者直接用单个字体文件的URL：

@font-face { font-family: 'CustomFont'; src: url('https://cdn.jsdelivr.net/gh/yourname/webfonts@1.0/SourceHanSansCN-Regular.woff2') format('woff2'); font-display: swap; }

这种方式的优点是不需要自己买流量、不需要配置CDN，只要维护好GitHub仓库就行。缺点是：如果你在GitHub上修改文件但忘了更新版本号，浏览器会因为缓存问题继续用旧字体，调试成本高。

如果你的项目已经有完整的云服务基础设施，比如阿里云OSS、腾讯云COS或者七牛云，那我更建议直接把字体传到对象存储里，开启CDN加速域名。这样你能精确控制缓存策略、防盗链、访问日志，字体文件和业务资源在一个体系内，后续维护也统一。

4.3 CDN引入的版本控制与跨域问题

用CDN引字体，有一个很容易被忽略的坑：跨域。字体文件属于“需要CORS”的资源，如果CDN服务器返回的响应头里没有Access-Control-Allow-Origin，浏览器可能拒绝加载。Google Fonts和jsDelivr这两家都对字体文件做了完整的CORS支持，所以直接用没问题。但如果你自己搭了个小CDN，或者用某些对象存储的默认域名，很有可能漏配CORS。

排查跨域问题很简单，打开浏览器的开发者工具，切到Network面板，刷页面后找到字体文件请求，看它的HTTP状态码和响应头。如果状态码是200但浏览器控制台报跨域错误，说明响应头里缺少CORS信息。

国内对象存储的配置路径一般是：在存储桶（Bucket）设置中找到“跨域设置”，添加一条规则，允许的来源*（或你的域名），允许的方法GET，允许的响应头加上ETag等。配置完成后等一两分钟生效，再刷新页面验证。

另外，CDN引入时建议在URL后面跟上版本参数或者把版本信息放在路径里，比如@1.0。这样当你更新字体文件时，变更版本号就能强制用户获取新文件，避免因为CDN缓存导致用户一直用旧字体。

5. 常见问题与性能优化实录

5.1 字体没生效的排查清单

换了字体却一直不生效，这是后台私信里问得最多的问题。我把排查路径整理成一张表，遇到问题直接按这个顺序过一遍：

5.2 性能优化：中文字体子集化与按需加载

如果你决定自托管中文字体，性能优化的重点就是“别把整个字库都发给用户”。中文字体几千个常用字，但一篇文章实际用到的字可能就几百个。子集化的思路就是：把字体文件里你真正用到的那些字“抠”出来，单独生成一个小文件。

用fonttools做子集化相当方便：

# 生成只包含常用3500字的子集 pyftsubset SourceHanSansCN-Regular.otf \ --text="的一是在不了有和人这中大为上个国我以要他时来用们生到作地于出就分对成会可主发年动同工也能下过子说产种面而方后多定行学法所民得经十三之进着等部度家电力里如水化高自二理起小物现实加量都两体制机当使点从业本去把性好应开它合还因由其些然前外天政四日那社义事平形相全表间样与关各重新线内数正心反你明看原又么利比或但质气第向道命此变条只没结解问意建月公无系军很情者最立代想已通并提直题党程展五果料象员革位入常文总次品式活设及管特件长求老头基资边流路级少图山统接知较将组见计别她手角期根论运农指几九区强放决西被干做必战先回则任取据处队南给色光门即保治北造百规热领七海口东导器压志世金增争济阶油思术极交受联什认六共权收证改清己美再采转更单风切打白教速花带安场身车例真务具万每目至达走积示议声报斗完类八离华名确才科张信马节话米整空元况今集温传土许步群广石记需段研界拉林律叫且究观越织装影算低持音众书布复容儿须际商非验连断深难近矿千周委素技备半办青省列习响约支般史感劳便团往酸历市克何除消构府称太准精值号率族维划选标写存候毛亲快效斯院查江型眼王按格养易置派层片始却专状育厂京东识述属构” \ --output-file=SourceHanSansCN-Regular.subset.woff2

上面这个命令里--text后面的内容就是你要保留的字。实际项目中，你可以先用爬虫抓取自己网站所有页面的正文文本，去重后提取字表，再生成对应的子集文件。这样生产环境字体文件可能从几MB缩到50KB左右，加载速度肉眼可见地提升。

但子集化也有代价：如果你的博客有评论功能，用户评论里可能包含你没收录的生僻字，这些字就会回退到系统字体，排版稍微不统一。折中方案是“主字体子集化 + 回退字体”，正文用子集化字体，评论区或者自由文本区域用完整字库字体。

5.3 缓存、预加载与渲染体验调优

字体文件属于静态资源，缓存策略可以比HTML更激进。如果你是自托管，建议在服务器或CDN上给字体文件设置Cache-Control: public, max-age=31536000, immutable。这个一年的缓存时间看着夸张，但字体文件本质上是带版本号的不可变资源，只要URL不变，内容就应该不变，所以大胆缓存没问题。

另外可以用<link rel="preload">提前让浏览器知道字体文件的存在，尤其是首屏就要用到的字体：

<link rel="preload" href="/fonts/SourceHanSansCN-Regular.woff2" as="font" type="font/woff2" crossorigin>

注意：preload字体请求必须带crossorigin属性，即使字体文件和HTML同源，也建议加上。这是因为字体请求默认走CORS模式，不带这个属性可能导致预加载请求被忽略，等于白写。

我在一个内容站上实测过：加上preload后，字体开始下载的时间从600ms左右降到200ms以内，首屏文字的字体替换延迟明显缩短。但建议只预加载首屏真正用得到的字体，多个字体文件全部预加载反而是浪费带宽。

5.4 版权与合规提醒

最后必须提醒一个容易翻车的地方：字体版权。中文字体是版权重灾区，很多看起来“能下载”的字体其实只允许个人使用，不允许商用。你在网上随便找一个“免费可商用中文字体包”下载，里面可能混着未授权的商业字体，一旦你的网站有广告收入、电商功能，或者公司业务在用，被字体厂商发律师函的案例并不少见。

我常用的做法是：

• 优先选明确开源授权的字体：思源系列、阿里巴巴普惠体、得意黑、站酷系列（部分含限制条件）。
• 如果一定要用商业字体，去官网确认价格和授权范围，保留授权文件。
• 在项目的README或者LICENSE文档里记录每个字体的授权来源，方便后续审计。

自托管字体文件时还要注意一个细节：有些开源字体虽然允许商用，但明确要求不得单独提取字体文件嵌入到其他软件或转售。如果你的网站允许用户下载字体文件，最好在下载页加上授权说明，避免替用户承担违规风险。

6. 两条路怎么选，我的建议

做了这么多字体替换的项目，我的体感是：个人博客、内容站、临时项目，优先CDN引入，图个省事；公司官网、SaaS产品、对用户体验有极致要求的项目，直接引入，自己能掌控的东西永远最靠谱。

如果你在国内有大量用户，CDN方案我倾向于使用国内公共资源库或国内容器镜像，避开海外服务导致的加载波动。追求稳定的话，直接引入加子集化是性能上限最高的方案。

最后分享一个小技巧：无论你最后选了哪种引入方式，一定要在真实网络环境下用开发者工具的Network面板看一遍字体文件的加载时序。我经常看到有人本地一切正常，部署后字体死活不生效，多半就是跨域、缓存、路径这三个问题。按文章里给的方法排查，基本10分钟内都能定位到原因。