在 tailwind.config.js 中通过 theme.extend.fontfamily 添加自定义字体别名，如 heading: ['zilla slab', 'serif']，同时必须手动在 css 中用 @font-face 声明同名字体，tailwind 仅生成 class 不处理字体加载。
tailwind.config.js 里怎么加自定义字体（fontFamily）
直接在 theme.fontFamily 下扩展即可，不是覆盖整个 fontFamily 对象，而是用 extend —— 否则默认的 sans、serif 全没了。
常见错误是写成这样：
fontFamily: {
sans: ['Inter', 'system-ui']
}
这会删掉 Tailwind 原有的所有字体别名，导致 font-serif、font-mono 失效。正确做法是只扩展现有配置：
- 用
extend键往默认 fontFamily 里加新别名，比如heading或display - 每个字体数组第一项是自定义字体名（如
'Zilla Slab'），后面接 fallback 字体和通用族名（'serif'） - 确保字体文件已通过
@font-face加载或 CDN 引入，Tailwind 只管生成 class，不负责加载字体
为什么 @font-face 必须手动写，不能靠 Tailwind 插件自动注入
Tailwind 的 fontFamily 配置只生成 CSS 类（如 font-heading），它不会生成 @font-face 规则。这是设计使然：字体加载策略（本地路径、CDN、子集、display 属性）太依赖项目上下文，插件没法统一处理。
典型遗漏点：
- 只配了
tailwind.config.js，但没写@font-face，结果页面显示为 fallback 字体 -
@font-face的font-family名和 config 里写的不一致（大小写、空格、引号），导致匹配失败 - 用了
font-display: swap却没考虑 FOUT/FOIT，首屏文字闪动明显
示例中 @font-face 的 font-family 必须和 config 里完全一致：
@font-face {
font-family: 'Zilla Slab';
src: url('/fonts/ZillaSlab-Regular.woff2') format('woff2');
font-weight: 400;
font-display: swap;
}
对应 config 写法：heading: ['Zilla Slab', 'serif']
用 plugin 注册字体 class 和 @font-face 的边界在哪
Tailwind 官方插件机制（addBase、addComponents）能帮你把 @font-face 注入到 CSS 输出里，但仅限于静态资源路径已知、无需运行时判断的场景。它不是“自动发现字体并注入”，而是你手写规则，插件帮你塞进构建流程。
适合用插件的情况：
- 多个项目共用同一套字体声明，想抽成 npm 包复用
- 需要根据环境变量切换字体源（如 dev 用 local，prod 用 CDN）
- 配合字体子集工具，在构建时动态生成
@font-face
不适合强依赖插件的原因：
- 绝大多数项目字体就几个，硬编码
@font-face更直观可控 - 插件里写死路径（如
url('./fonts/xxx.woff2')）容易因打包器差异出错 - 调试时，直接看 CSS 文件比翻插件源码快得多
字体加载失败时 tailwind 字体 class 还生效吗
生效。只要 class 被应用（如 font-heading），CSS 就会尝试匹配 font-family 列表里的第一个名字。但若该名字未被任何 @font-face 声明，浏览器就跳到第二个，依此类推——最终落到系统字体上。
这意味着：
- 字体加载失败 ≠ class 失效，只是渲染效果降级
- 别在
fontFamily数组里写不存在的字体名（如'MyCustomFont'却没声明@font-face），否则整行 fallback 都会被跳过 - 可以用
font-display: optional让浏览器跳过加载慢的字体，但需权衡可访问性
最容易被忽略的是：字体文件 404 时，控制台可能只报一个 network error，但页面看起来“好像只是字体变了”，没人意识到是路径错了。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
