网站字体搭配实战:我用在线工具测遍 50 套方案的完整记录

选字体不难,难的是搭字体。选了一个漂亮的衬线标题字,配上一个清晰的无衬线正文字,两者放在一起却总觉得哪里不对:太像、太跳、或者毫无章法。

我之前给博客做改版时,对着 Google Fonts 目录挑了接近三个小时,最终卡在"预览截图好看不代表上线排版好看"这道坎上。后来用 字体搭配生成器 把 50+ 套真实项目跑过的搭配排在一起实时渲染,问题才算真正解决。这篇文章记录我从选字到落地的完整流程,包含真实的 CSS 输出,以及几个我踩过的坑。

为什么一个字体不够用

整页用同一种字体,哪怕是 Inter 这种公认好看的无衬线字,读起来会很单调。标题和正文的视觉重量相同,扫读时抓不到层级,眼睛需要额外做功才能区分"这是小标题"还是"这是正文段落"。

头部刊物和产品站几乎都在混搭:Medium 用 Charter(衬线)配 Source Sans(无衬线),Vercel 用 Geist Display 配 Geist Mono,纽约时报用 Cheltenham 配 Imperial。这些不是美学偏好,是经过大流量规模验证的可读性决策。根据 Typewolf 对高权重英文博客和刊物站的抽样统计,衬线与无衬线混搭方案占比超过 65%,纯无衬线约占 28%,纯衬线仅占个位数,对比数字本身已经说明问题。

衬线 vs 无衬线:搭配背后的设计逻辑

衬线字(Serif,比如 Playfair Display、Lora、Cormorant)笔画末端有装饰短线,视觉重量更强、历史感更浓。标题用衬线,读者的眼睛自然被它吸引,层级一目了然。

无衬线字(Sans-serif,比如 Inter、Source Sans、Open Sans)笔画干净,小字号下屏幕渲染清晰,长文正文首选。

两者混搭利用了视觉对比:标题的衬线给页面性格和落点,正文的无衬线保障可读性。反过来,无衬线标题配衬线正文同样成立:这是 Substack 和早期 Kindle 的路子,长文阅读舒适度好。纯衬线对纯衬线、纯无衬线对纯无衬线也可以,但需要靠字重差距拉开层级,比如 Inter Black 标题配 Inter Regular 正文。

实操:在工具里选搭配的完整流程

进入 字体搭配生成器 后,我先做两件事:把样张文字换成自己实际会用的内容,然后按风格筛选。

我做的是一个轻科技内容博客,在风格筛选里选了 editorial(刊物),样张文字改成:"设计不是装饰,是解决问题的一种方式。"

筛选后工具给出一排实时渲染的搭配卡。我停在 Playfair Display + Source Sans 3 上:标题字大而有力,正文在 16px 下清晰,两者对比明确但不突兀。

点击"复制 CSS",输出如下:

@import url('https://fonts.googleapis.com/css2?family=Playfair+Display:wght@400;700&family=Source+Sans+3:wght@400;600&display=swap');

h1, h2, h3 {
  font-family: 'Playfair Display', serif;
}

body {
  font-family: 'Source Sans 3', sans-serif;
}

贴进全局样式表,刷新页面,效果立刻出来。这是我对着 Google Fonts 三小时没达到的效果,工具五分钟搞定。

注意 @import 里的 wght@400;700:只引了两个字重。根据 Google Fonts 官方性能文档,把字重限定到实际使用的数量,字体加载体积比引入全字重减少约 60%–70%,直接改善 LCP(最大内容渲染时间)。工具生成的 CSS 已经按这个最佳实践处理,不需要手动调整。

中文站的特殊考量

库里有 4 套 CJK 搭配,其中思源宋体 + 思源黑体是我测下来最稳的选择:思源宋(Source Han Serif)做标题,思源黑(Source Han Sans)做正文。知乎和 Medium 中文版都在用这套组合,经过大流量考验。

如果页面是中英双语,比如英文标题配中文正文说明,要在 font-family 里显式补中文兜底:

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

不补的话,中文字会静默回退到系统字体:Windows 上大概率是微软雅黑,Mac 上是苹方。三台机器显示三个样,比不用 Google Fonts 之前更乱。

还有一个性能问题要注意:中文字体单个字重通常在 3–6MB,比拉丁字体大 20–30 倍。如果主要用户是中文读者,建议用系统字体栈做正文,Google Fonts 的中文字体只用在展示性的短标题上:这样既保证了中文渲染质量,又不把首屏加载时间拖垮。

把字体 CSS 落地进 Tailwind 或 Next.js

用 Tailwind 的项目,把两个字族写进 tailwind.config.js:

theme: {
  fontFamily: {
    display: ['"Playfair Display"', 'serif'],
    body: ['"Source Sans 3"', 'sans-serif'],
  },
}

之后 font-display 和 font-body 就是可用的工具类,样式层不需要再写任何 CSS。

Next.js 13+ 推荐用 next/font/google 替代 @import,因为 @import 在 CSS 文件里会触发一次额外的阻塞 round trip。根据 Google Web Vitals 文档的记录,这会在典型移动连接上增加约 150–200ms 的网络开销:

import { Playfair_Display, Source_Sans_3 } from 'next/font/google'

const playfair = Playfair_Display({ subsets: ['latin'], weight: ['400', '700'] })
const sourceSans = Source_Sans_3({ subsets: ['latin'], weight: ['400', '600'] })

字体在构建时下载到本地,完全绕开 Google Fonts CDN 的阻塞请求,LCP 可以进一步改善。

如果你还在用系统默认字体栈,准备接入 Google Fonts 之前可以先用 CSS 字体栈生成器 把现有栈梳理规范:它能帮你生成带各操作系统兜底的完整 font-family 声明,确保切换到 Google Fonts 后兜底链不断。

---

Made by Toolora · Updated 2026-06-07