接手一个内容型站点的新需求设计师丢过来一个中文字体包要求页面正文、标题全部换成这种风格。做之前以为就是加一条 CSS 的事真上手才发现中文字体跟英文字体完全是两个物种——英文一个单词文件才几十 KB中文一个字体包动辄 5MB 往上想用 CDN 引入省事吧得评估公共节点稳不稳想直接引入放到自己服务器又得操心带宽、缓存、加载顺序稍不注意页面先白屏两秒再哗啦一下出字。这篇文章不说虚的把我实际用过的两种方式完整拆一遍。先讲清楚中文字体为什么难搞、字体怎么选再分别走一遍 CDN 引入和直接引入的落地步骤最后把子集化、font-display、跨域这些绕不开的优化点和坑位都列出来。后端、运维、前端的朋友应该都能直接照着抄。1. 换字体之前先搞懂中文字体为什么这么“重”1.1 一个中文字体包为什么能到 5MB很多人第一次接触中文字体部署第一反应是“不就是一个静态文件吗”。直到把 .ttf 传到服务器看一眼大小才意识到不对。原因在于字符集。英文字体只需要覆盖 26 个大小写字母、数字和常见标点撑死几百个字形所以哪怕做成高精度的可变字体体积也普遍在 50KB 到 200KB 之间。中文字体要覆盖的是数千到数万个汉字GB2312 标准收录 6763 个汉字GBK 扩充到 20902 个Unicode 的 CJK 统一汉字区有两万多如果做全字库字形数量可以到 7 万以上。每一个汉字都要有独立的矢量轮廓数据这体积压不下来。拿开源的思源黑体来说Source Han Sans SC 一个字重的 OTF 文件在 8MB 到 16MB 上下思源宋体更夸张。英文那段字重 400 的 RobotoTTF 也就 170KB 左右。差距是几十倍甚至上百倍所以“换中文字体”这件事从第一天起就不是装饰问题是性能问题。1.2 换字体不只是“改个 font-family”font-face 声明下去浏览器拿到字体文件这中间有一套完整的加载和渲染流程。字体文件没加载完时页面上的中文到底显示什么取决于font-display属性的设置而它直接决定用户看到的是白屏、系统默认体、还是“先默认体后新字体”的闪跳。另外还有一个容易被忽略的点中文字体文件大浏览器不仅要下载还要解析字形表把这个过程放在页面关键渲染路径里效果很糟糕。要是再赶上服务器带宽不够、用户网络差整个页面被一个字体文件拖垮的情况我见过不少。所以中文字体的引入策略核心就是“怎么让用户尽快看到内容同时尽量让新字体生效”。1.3 CDN 引入 vs 直接引入先分清方案边界先说结论这两者在实际生产里不是“二选一”而是可以组合使用的。CDN 引入通常指页面通过link加载公共 CDN 上的字体样式表或字体文件典型比如 Google Fonts、jsDelivr 上的字体包。你也可以把字体文件传到自己的对象存储套一层 CDN 加速域名这也算 CDN 引入而且是我最推荐的生产方案。直接引入指把字体文件下载到项目静态目录通过相对路径在 CSS 里font-face引用资源跟随应用一起部署。两者的差异主要在托管位置、性能和可控性上维度CDN 引入公共 CDN直接引入自托管/C DN托管接入成本只需一行 link基本不用维护需要下载、转换、写 font-face性能依赖公共节点区域差异明显可控可配合自建加速节点稳定性被第三方变更牵制完全自主隐私合规第三方可能记录访客信息不涉及往外传数据适用场景Demo、个人站、可接受第三方依赖生产业务、企业站点、对性能敏感我的建议很直接小项目无所谓怎么方便怎么来正经生产环境一定用“直接引入 自建 CDN 托管”的组合。这个方案既能保证字体可控又能拿到 CDN 的边缘加速。2. 字体怎么选格式、授权、字体栈2.1 免费可商用的中文字体清单选字体第一原则不是好看而是授权。我给自己排过一份常用清单都是可以比较放心用在中后台和内容站的思源黑体Source Han Sans / Noto Sans SCAdobe 与 Google 联合发布OFL 开源协议最稳妥的黑体选择。思源宋体Source Han Serif / Noto Serif SC同样是 OFL 授权适合正文阅读量大的内容型站点。阿里巴巴普惠体阿里免费商用字重多覆盖广偏现代。得意黑Smiley Sans有特征的开源标题字体OFL 授权适合做头图和标题不适合正文。站酷系列站酷高端黑、站酷快乐体等基本都可免费商用但需要遵守站酷的授权条款。MiSans小米推出的免费商用字体字重很全观感干净。这里必须多说一句免费商用不等于可以为所欲为。有的字体要求你不能单独售卖字体文件有的要求引用页面保留署名有的对“修改字体”有额外限制。上线前把授权页打开看一眼花不了十分钟但能避免后面吃大亏。2.2 字体格式怎么选WOFF2 是首选字体文件格式有 TTF、OTF、WOFF、WOFF2浏览器兼容性和体积差异很大格式压缩情况浏览器支持使用建议TTF无压缩体积最大几乎全部开发素材、转换源文件OTF部分压缩排版特性丰富现代浏览器同上注意旧 IE 不支持WOFF基于 zlib 压缩IE9、现代浏览器兼容兜底WOFF2基于 Brotli 压缩体积最小所有现代浏览器不支持 IE线上首选WOFF2 对中文字体的压缩效果非常明显同样内容通常比 TTF 能再小 30% 到 50%。生产环境我基本只发布 WOFF2最多留一个 WOFF 兜底给旧浏览器。TTF 只作为本地的转换原始文件不会直接丢到线上给用户下载。2.3 中文字体栈怎么搭字体栈的核心逻辑是第一个是你想要的新字体后面跟着系统里常见的中文字体兜底最后放一个通用字体族。body { font-family: MyChineseFont, PingFang SC, HarmonyOS Sans SC, Microsoft YaHei, Hiragino Sans GB, sans-serif; }这个顺序有讲究macOS / iOS 上可能没有 “Microsoft YaHei”Windows 上没有 “PingFang SC”Linux 上可能什么都没有。让系统去匹配第一个可用的中文字体用户永远能看到字而不是看到方框。很多新手只写一个自定义字体一旦加载失败就满屏豆腐块其实不是字体坏了是字体栈没搭好。3. 直接引入把字体文件放进项目里3.1 下载字体后先做格式转换设计师给过来的通常是 TTF 或 OTF直接引用不是不行但体积和解析性能都比较吃亏。我习惯先把字体转成 WOFF2再放进项目。在线转可以用 transfonter.org 这类工具把字体拖进去勾选 WOFF2 和 WOFF导出即可。本地批量处理用 fonttools 更方便# 先安装 fonttools 及 woff2 支持 pip install fonttools brotli # 将 OTF 转为 WOFF2 pyftsubset SourceHanSansSC-Regular.otf \ --flavorwoff2 \ --output-fileSourceHanSansSC-Regular.woff2 # 转 WOFF 做低版本兜底 fonttools ttLib SourceHanSansSC-Regular.otf -o SourceHanSansSC-Regular.woff --flavorwoff这里要注意如果字体是 OTF/CFF 格式部分老工具处理起来日志会报错但 fonttools 基本都能搞定只要版本不太旧。3.2 font-face 标准写法与常见坑放进项目后在 CSS 里声明字体家族font-face { font-family: MyChineseFont; src: url(../fonts/MyChineseFont.woff2) format(woff2), url(../fonts/MyChineseFont.woff) format(woff); font-weight: 400; font-style: normal; font-display: swap; }几个细节我都是踩过坑才记住的font-weight一定要写对。如果字体文件本身就是 Regular但 CSS 里给 700浏览器会拿它去模拟粗体效果发虚如果 font-face 只声明了 400页面又用了font-weight: 600浏览器可能做出一次质量很差的 fake bold。路径要跟着构建工具走。Vite/Webpack 里如果字体放在src/assets别写相对路径写死用项目约定的别名或静态资源目录否则打包后路径会断。不是声明了就万事大吉要用真实浏览器打开 Network 面板确认字体请求返回 200。字体不生效的排查第一步永远是看请求。3.3 直接引入适合什么场景直接引入最大的优势是简单、可控、不依赖第三方适合内部系统、管理后台、低频访问的页面。因为这种场景用户数量有限字体文件走自己的服务器也扛得住。但它有天然短板中文字体即使做了基本压缩首屏仍有几百 KB 甚至几 MB如果服务器在北方、用户在南方跨地域下载就慢如果访问量突然上来字体文件这种大静态资源会疯狂占用出口带宽。所以一旦业务量起来我就把它升级成自建 CDN 托管字体文件放对象存储用加速域名分发。4. CDN 引入从公共 CDN 到自建加速4.1 公共 CDN一条 link 解决但别做生产依赖最常见的公共 CDN 方式是 Google Fonts它会把字体按照当前页面用到的字符子集化再通过 unicode-range 拆成多个小文件浏览器只下载需要的那几块策略本身很先进。link relpreconnect hrefhttps://fonts.googleapis.com link relpreconnect hrefhttps://fonts.gstatic.com crossorigin link relstylesheet hrefhttps://fonts.googleapis.com/css2?familyNotoSansSC:wght400;500;700displayswap 用起来确实简单但有一个绕不开的问题Google Fonts 的节点主要在境外国内用户在部分网络环境下访问延迟很高甚至拿不到字体样式表。做个人项目、Demo、对国内访问没有要求的场景可以随便用做面向市场的产品我一般不推荐把它写死在生产环境。类似思路还有 jsDelivr 上托管的 Fontsource 字体包比如 fontsource/noto-sans-sc它同样做了子集化和 unicode-range 拆分link relstylesheet hrefhttps://cdn.jsdelivr.net/npm/fontsource/noto-sans-sc5.0.3/index.css 公共 CDN 的通病都一样节点位置、可用性、策略调整都不由自己控制。哪怕今天速度不错明天换了节点策略或者运营商解析出了幺蛾子你一点办法都没有。所以我把这条路径定位成“应急或尝鲜”不是生产方案。4.2 自建 CDN对象存储 加速域名这是我在生产环境里最常用的做法。把字体文件传到对象存储绑定 CDN 加速域名整个流程大概是这样的第一步创建对象存储桶。阿里云 OSS、腾讯云 COS、七牛云都行操作逻辑类似。把子集化后的 WOFF2 文件传上去目录结构建议按项目或版本分比如fonts/noto-sans-sc/v1/Regular.woff2方便后面做版本管理。第二步在云厂商的 CDN 控制台添加加速域名。源站类型选“对象存储”再选对应的 bucket。如果没有自定义加速域名可以先绑定一个二级域名比如cdn.example.com。第三步去 DNS 服务商处把加速域名 CNAME 解析到 CDN 分配的节点域名。这一步各地生效时间不一样快则几分钟慢则小半天不用急。第四步配置缓存。字体文件属于几乎不变的静态资源可以放心设置长缓存Cache-Control: max-age2592000, immutable五天还是三十天看你习惯我习惯给一个月。字体文件替换时不要用原地覆盖而是改个文件名或版本目录这样能利用 immutable 缓存又不怕客户端拿到旧文件。第五步配置 HTTPS 证书。现在的站点基本都是 HTTPS字体资源如果还是 HTTP浏览器会直接拦截请求字体就静默失效。好在各云厂商都支持免费证书一键申请。配置完成后可以用 curl 验证一下curl -I https://cdn.example.com/fonts/noto-sans-sc/v1/Regular.woff2重点看返回头里的content-type、cache-control和x-cache字段。x-cache能看出这次请求是命中了 CDN 节点还是回源拿了。4.3 CDN 为什么能帮上忙CDN 的核心机制不复杂把同一份内容缓存到全国甚至全球各地的边缘节点用户访问时DNS 解析会把请求导向离用户最近的节点而不是固定打到源站。中文字体文件再小也有几百 KB如果每个用户都从源站拉源站带宽压力大用户跨地域体验也不稳定。套上 CDN 后边缘节点缓存住字体文件只要缓存没失效后续用户都从最近的节点拿数据速度和稳定性一下子就有了保障。这也是为什么 CDN 节点选址只在一众算法题里反复出现——它本质上是在找“一组能最小化用户访问代价”的节点集合。实际业务里我们不必自己算云厂商的调度系统会自动处理但至少知道这个逻辑排查问题时就会往“节点覆盖够不够”“回源是否频繁”这个方向想。5. 性能优化是换字体的大头5.1 先做子集化别拿全量字体上生产字体再换格式全量中文还是大所以真正的杀手锏是子集化只保留页面中实际用到的字符。第一种是静态子集化工具。比如 font-spider字蛛它会扫描你指定的 HTML/CSS 文件找出所有涉及到的字符然后裁掉字体文件里没用的字形生成新的子集字体。用法很简单npm install -g font-spider font-spider ./dist/index.html前提是 CSS 里的font-face路径要写对字蛛才发现并处理这些字体文件。处理完后它会生成新的精简字体并把 CSS 里的 font-face 指向新文件。第二种是命令行精确控制。用 fonttools 的 pyftsubset 指定字符集适合页面内容明确、只包含少量文案的场景pyftsubset SourceHanSansSC-Regular.otf \ --text欢迎访问我们的网站这里展示最新产品与活动信息。 \ --flavorwoff2 \ --output-filesubset.woff2如果你的页面是内容管理系统用户会输入各种文本框里的动态数据静态子集化就覆盖不了未来可能出现的新字符。这时候可以在把页面静态文案拿去子集的基础上再把业务上的高频字用户名、分类名、常用词人工追加进去保证大多数情况不会缺字。子集化效果有多明显我举一个真实例子一个落地页只用了 800 多个汉字原字体思源黑体一个 OTF 大概 16MB子集化并转 WOFF2 之后基本在 150KB 到 300KB 这个区间。文件小了很多问题跟着就没了。5.2 动态子集化按需分段加载静态子集化适合页面字少且固定内容型站点字数多且不固定怎么办更稳的是动态子集化把整个字体文件按 unicode-range 切成很多份浏览器滚动到哪、需要哪个字符就只下载对应的字体块。Google Fonts 用的就是这套思路。自建方案里有开源工具 cn-font-split它能把一个完整中文字体切成几十个按区间划分的 WOFF2 小文件并生成对应的 font-face 和 unicode-range 逻辑。使用方式大致是命令行指定输入输出npx cn-font-split src/path/to/font.otf output/path/to/output这个工具迭代很快具体参数以项目 README 为准。切完之后你会得到一堆几十 KB 的小字体文件和一个 CSS 文件页面引用这个 CSS浏览器就会按需拉取。动态子集化的烦恼是文件数量多但好处是任何页面都敢上全字库字体。对于内容平台这种用户输入不可控的场景这个方案比手工静态子集化可靠得多。5.3 font-display 的取舍font-display 控制字体加载期间的渲染行为对中文字体的体验影响极大取值加载期间表现适用场景block最多隐藏文字 3 秒等字体加载不推荐用于正文swap先用兜底字体加载完成替换最常用但有闪跳fallback极短等待超时则用兜底不再替换推荐optional浏览器按网络状况决定是否换字体对性能要求极高我实际用下来正文一般用swap或fallback。如果字体文件已经被子集化到很小swap 的闪跳时间短到用户基本无感。如果做的是标题这种大面积装饰字block 造成的白屏非常可怕我会放弃这个视觉完全对齐的想法给用户看到字比什么都重要。5.4 预加载与连接池如果某个字体是首屏必须的可以加 preload 让它提前下载而不是等 CSS 解析到了再发请求link relpreload hrefhttps://cdn.example.com/fonts/title.woff2 asfont typefont/woff2 crossorigin 这里crossorigin属性必须写。就算字体是同源的preload 的请求默认也走 CORS 模式不写这个属性字体文件会被浏览器忽略开发者工具里能看到“在 preload 中请求字体但未使用 crossorigin”的告警。preload 不要贪多。多个 WOFF2 一起 preload等于主动把首屏带宽全占了反而拖慢页面。我的经验是只 preload 最重要的那一两个字重比如标题的 Bold 字重正文用了多字重就不预加载。6. 常见问题与排查套路6.1 字体始终不生效先查这三处字体不生效是我被问到最多的问题排查顺序我总结成了三步第一步打开开发者工具 Network过滤 Font 请求看字体文件是不是真的返回了 200。如果压根没有请求说明 CSS 里引用的 font-family 名和 font-face 声明不一致或者把 fallback 字体名写到了前面去。第二步看请求返回的状态码。404 是路径问题尤其注意构建工具的 base 路径部署到子目录时相对路径会失效403 可能是服务器的静态资源权限或防盗链设置导致。第三步看页面上生效的 font-family。DevTools 的 Computed 面板里可以看到实际计算后的字体栈如果第一个自定义字体旁边有黄色警告说明浏览器没有找到这个字体声明。6.2 CORS 跨域导致字体加载失败CDN 引入字体最常见的报错就是Access to font at https://cdn.example.com/fonts/xxx.woff2 from origin https://www.example.com has been blocked by CORS policy原因是字体文件在跨域的 CDN 域名下浏览器默认不允许这种跨域字体请求被应用到页面。解决办法是在 CDN 或者对象存储的响应头里加上Access-Control-Allow-Origin: *如果你对安全要求更严格可以只放行自己的域名。这个配置做完要清 CDN 缓存生效不然测试会一直以为自己没配置对。另外前面提到的 preload 带crossorigin也是专门针对这种跨域情况的。6.3 首屏闪跳和白屏怎么压下去闪跳FOUT在白底页面尤其明显往往表现为“文字先是宋体过一会突然变成黑体”。白屏FOIT则更严重字体加载期间文字整个消失。解决思路不是“不要闪跳”而是“把闪跳窗口压缩到感知不到”。做法就是前面几节说过的子集化 WOFF2 CDN font-display 组合。我实际调下来一个经过子集化的标题字体文件在 50KB 左右时swap 的替换几乎是瞬间完成的用户根本感觉不到变化如果文件还在 1MB 以上任何 font-display 策略都救不了体验。6.4 版权风险要提前规避上线前的最后一步我建议把字体授权再核对一遍。中文字体的版权情况比英文复杂很多很多“免费可商用”的中文字体也有附加条款比如不能用于商标、不能嵌入到硬件、不能单独转售。用子集化工具裁剪字体属于对字体的修改行为OFL 协议下一般允许但商业字体的 License 可能禁止这点要和字体版权方确认。不要等站子做大了再被发函那个时候换字体的成本特别高。6.5 顺带说一句终端里的中文字体中文字体问题不止在网页上存在。很多人用终端工具比如 Xshell 连服务器时会遇到中文乱码或者字体发虚原因无非两个一是会话编码不是 UTF-8二是终端字体本身不支持中文。解决办法是在终端外观设置里把编码切到 UTF-8再给字体栈选一个能覆盖中文的字体比如“JetBrains Mono PingFang SC”这种组合。原理和网页字体栈是相通的一个主字体管英文和代码一个 fallback 字体管中文显示。我现在做中文字体接入的默认套路已经固定了下载 OTF 原始文件用 fonttools 转 WOFF2按业务字符子集化发布到对象存储套 CDN 加速域名最后给页面上 font-face 加font-display: swap关键字重加 preload。这套流程从个人博客到日活几十万的站点都能直接复用区别只是子集化的颗粒度和 CDN 资源大小。最后再分享一个小技巧如果只是想给页面里某几个标题词换一种风格字体根本不用引入整个字体文件。把用到的十几个字单独子集化成一个 WOFF2几十 KB 就搞定然后单独给那个标题类名设置 font-family。这种“局部换字体”的做法在很多营销页和活动页里特别实用视觉上做出了差异化性能上几乎零负担。