尧图网站设计 尧图网站设计YAOTU DESIGN
ARTICLE DETAIL

资讯详情

深耕网站设计与一线实操的经验洞察。

开源中文字体Knora One的字体兜底配置与缺字检测实践

开源中文字体Knora One的字体兜底配置与缺字检测实践 前端做中文站点最怕的不是字体选得不好看而是选完字体后页面在用户机器上出现“豆腐块”。明明 CSS 里写了font-family但生僻字、冷门标点、多语言混排场景一进来字形直接消失或变成方框。这个问题本质上是字体兜底链没设计好。这次我们以开源中文字体 Knora One 为例完整演示一次字体兜底的配置、验证和排错流程讲清楚font-family到底该怎么写字体文件缺失时浏览器和操作系统会怎么处理以及如何用脚本自动化查出字体缺字。Knora One 本身是一个定位于屏幕阅读场景的开源中文字体覆盖简体中文常用字符集适合作为界面正文和内容展示字体。本文不把字形设计细节作为重点而是把它当作字体兜底功能演示的对象。我们会对比系统字体回退链、浏览器字体加载优先级、生僻字缺失处理、多语言混排兜底以及网络字体加载失败后的表现。整个过程不依赖专用硬件一台普通开发机就能完成读者可以照着在自己的项目中复现。文章会提供三部分可直接用的内容一套完整的 CSS 字体回退配置参考、一个本地测试页面、一段基于 fontTools 的缺字检测脚本。结尾会列出常见问题排查表和工程化建议。无论你是前端开发、还是负责公司内部 UI 规范这篇文章都能让你把“字体兜底”从玄学变成可验证的工程实践。1. 核心能力速览能力项说明演示对象Knora One 开源中文字体核心主题字体兜底Font Fallback机制适用系统Windows / macOS / Linux / Android / iOS零基础门槛不需要 GPU不需要特殊硬件环境要求浏览器、本地文本编辑器、可选 Python 3主要功能字体安装、CSS 回退链设计、缺字检测、加载优先级控制验证方式本地测试页面 浏览器 DevTools fontTools 脚本输出产物回退链配置、测试报告、检测脚本适合场景中文站点、多语言 App、低资源缓存受限的内嵌前端需要说明的是Knora One 的字符集覆盖、字重数量、授权协议版本应以官方发布渠道为准。本文档中用到的字体文件路径和命令均按通用开源字体发布包结构编写读者拿到实际文件后可做对应替换。2. 字体兜底是什么为什么重要“字体兜底”在不同技术栈里有不同叫法CSS 里叫font-family回退Windows 系统里叫“字体链接”macOS 里叫“字体级联”Android 上叫“字体回退表”。本质上做的是同一件事当前字体无法渲染某个字符时在字体列表中依次向后寻找能渲染该字符的字体并交给它绘制。举个例子一个很常见的 CSS 写法是body { font-family: Knora One, PingFang SC, Microsoft YaHei, sans-serif; }这段代码的含义是优先让页面使用 Knora One。如果 Knora One 中没有某个字符比如繁体字“龘”系统会接着尝试 PingFang SC如果 PingFang SC 也没有再试微软雅黑再到最后的sans-serif通用兜底。字体兜底最重要的意义不是“选好看的字体”而是“保证所有字符都能被渲染”。中文网页的问题是中文字体数量庞大单个字体文件几乎不可能覆盖全部汉字。GB 2312 约 6763 个汉字GBK 约 20902 个但 Unicode 汉字区超过 8 万个字符。日常使用没问题一旦出现生僻人名、古籍引用、网络用语造字缺字问题就立刻暴露。如果不设计兜底链浏览器最终会渲染成空方块也就是业内常说的“豆腐块”或“tofu”这个问题并不少见在某些政企系统的内网里、在老版本字体环境里出现概率比预期还高。字体兜底还会影响加载性能。网络字体加载失败或加载缓慢时font-display属性决定字符在字体加载完成前是否可见。默认值和swap、block、fallback、optional四种可选策略会让用户在慢网络下看到完全不同的效果。这也是字体兜底演示中必须覆盖的一部分——很多开发者只配置了字体来源没有配置加载策略导致弱网环境下整页文字空白好几秒。从工程角度看字体兜底不是一个“写一行字体声明”的动作而是一个“设计 验证 监控”的链路。你不仅要决定字体栈里放哪些字体还要确认每个位置上的字体真实覆盖了目标字符集并在发布前用脚本检测缺字情况。下面的章节就按这条链路逐步展开。3. Knora One 字体规格与使用边界先说清楚 Knora One 的定位。从公开资料看Knora One 是开源中文字体项目主要面向简体中文场景设计上偏向清晰、利落的无衬线黑体风格适合作为正文、标题和界面文案使用。这类字体的核心价值在字重清晰、屏幕渲染稳定、文件体积相对可控比较适合嵌入到 Web 项目或客户端安装包中。与思源黑体、阿里巴巴普惠体等全字重开源字体相比Knora One 覆盖范围更轻量适合对文件体积敏感的项目。这里需要注意不要把它当作超大字库字体来用如果项目需要完整覆盖 GB18030 字符集或者需要大量繁体、生僻字仍然要设计系统字体兜底链。在使用边界方面需要注意几点。第一任何开源字体都应先确认授权协议。通常开源中文字体会采用 SIL Open Font License 1.1 或同等级别的协议允许免费商用、自由嵌入但修改后需要更名、发布需附带协议文本。具体以 Knora One 官方发布说明为准本文不替代协议原文。第二字体兜底链里的“系统字体”在不同平台表现完全不同——Windows 自带微软雅黑、宋体、黑体macOS/iOS 自带苹方字体Android 中文字体由厂商定制。这意味着同一个 CSS 页面在不同设备上的实际渲染字形会有差异这不是 Bug而是字体兜底机制的预期行为。第三Knora One 作为网络字体加载时它应该只承担“优先字体”的角色不能承担“全部字符保证”的角色。多语言混排中日文假名、韩文音节、越南文拉丁扩展字符往往要依靠系统字体垫底。所以本节给出的结论是Knora One 适合做“主字体”但不适合做“唯一字体”。它能在视觉上有统一的风格但真正的完整渲染必须依赖一套设计良好的兜底链。下面我们从环境准备开始把这套链路跑通。4. 环境准备与前置条件字体兜底演示不需要重型开发环境但建议准备一台装了现代浏览器的开发机。以下清单按 Windows、macOS、Linux 通用整理。操作系统层面Windows 10/11、macOS 12、Ubuntu 22.04 都可直接演示。需要准备的组件包括现代浏览器Chrome 或 Edge 最新稳定版用于加载本地页面和查看 DevTools。文本编辑器VS Code、Sublime Text 或 Notepad用于编辑 HTML 和 CSS。字体查看工具Windows 自带的“字体设置”面板macOS 的“字体册”Linux 可以安装fontconfig。Python 环境可选用于运行 fontTools 缺字检测脚本建议 Python 3.8 以上。安装字体检测脚本依赖可使用命令pip install fonttools如果网络环境限制也可直接从 PyPI 下载对应的 wheel 包安装。fontTools 是纯 Python 库不依赖图形界面安装后就能解析 TTF/OTF/WOFF 字体文件并读取字符映射表是目前检查字体缺字最直接的工具。磁盘空间方面字体演示项目整体不超过 200MB其中字体文件通常几 MB 到十几 MB页面文件不到 1MB。不需要 GPU不需要虚拟机一块普通硬盘加任意开发机均可完成全部操作。在进行下一步之前先做一个简单的环境检查。在浏览器地址栏输入chrome://version确认浏览器版本号在终端执行python --version确认 Python 版本。如果已有 Python 环境却无法使用pip可先执行python -m pip install fonttools来保证安装到正确的解释器中。环境检查完成后进入字体获取与安装环节。5. 字体获取、安装与基础配置获取 Knora One 字体文件优先从官方发布渠道下载。开源字体发布包常见结构如下KnoraOne/ ├── KnoraOne-Regular.ttf ├── KnoraOne-Bold.ttf ├── KnoraOne-Regular.woff2 ├── KnoraOne-Bold.woff2 ├── OFL.txt └── README.md下载后先解压确认目录中包含 TTF 或 OTF 格式的原生字体文件以及 WOFF2 格式的 Web 字体文件。TTF 用于桌面安装WOFF2 用于 Web 嵌入。授权文件如OFL.txt需要保留后续发布时需附带。5.1 Windows 安装字体在 Windows 中直接右键点击KnoraOne-Regular.ttf选择“安装”。也可以多选字体文件后批量安装。安装完成后可通过“设置 - 个性化 - 字体”搜索框输入“Knora”确认是否已生效。如果想验证命令行也能识别打开 PowerShell 执行Get-ChildItem $env:WINDIR\Fonts | Where-Object { $_.Name -match Knora }5.2 macOS 安装字体macOS 下双击字体文件会打开“字体册”预览窗口点击“安装字体”即可。安装完成后在“字体册”中搜索“Knora”能看到字体家族列表。macOS 下如果要在命令行验证路径可以检查ls ~/Library/Fonts/ | grep -i knora5.3 Linux 安装字体Linux 桌面环境一般使用 fontconfig 管理字体。把字体文件复制到用户字体目录然后刷新缓存mkdir -p ~/.local/share/fonts cp KnoraOne-*.ttf ~/.local/share/fonts/ fc-cache -f fc-list | grep -i knorafc-list输出了字体名称和文件路径说明字体已注册成功。这一步在后续自动化检测中也可以用来判断字体是否安装到位。5.4 项目目录初始化新建一个演示项目目录把 Web 字体文件放在里面font-fallback-demo/ ├── fonts/ │ ├── KnoraOne-Regular.woff2 │ ├── KnoraOne-Bold.woff2 │ └── OFL.txt ├── index.html └── style.css这里要注意目录命名规范。来源与版本信息可以用README.md记录便于后续排查字体加载问题。6. Web 场景下的字体兜底配置字体安装完成后Web 项目的配置重点在于用font-face声明字体来源用font-family设计回退链用font-display控制加载策略三个部分缺一不可。6.1 font-face 声明创建一个style.css写入以下内容font-face { font-family: Knora One; src: url(./fonts/KnoraOne-Regular.woff2) format(woff2); font-weight: 400; font-style: normal; font-display: swap; } font-face { font-family: Knora One; src: url(./fonts/KnoraOne-Bold.woff2) format(woff2); font-weight: 700; font-style: normal; font-display: swap; } body { font-family: Knora One, PingFang SC, Hiragino Sans GB, Microsoft YaHei, WenQuanYi Micro Hei, sans-serif; font-weight: 400; line-height: 1.75; }这里有几处容易踩坑的细节。第一src路径要相对于 CSS 文件路径。如果 CSS 在css/目录下而字体在fonts/目录下就得写成../fonts/...。相对路径写错是最常见的字体加载失败原因浏览器并不会报错只在 Network 面板里表现为 404。第二font-family的名字必须和font-face声明里一致不能带引号差异或多余空格。这里统一使用Knora One。第三字体栈的顺序非常重要。越靠前的字体优先级越高但只针对“能渲染当前字符”的情况。如果第一位字体缺字浏览器会跳到下一位而不是整段文字切换。这意味着字体栈前面的字体影响视觉风格后边的字体只影响兜底覆盖范围并不是“越往后越差”。第四PingFang SC是 macOS 和 iOS 的中文字体Microsoft YaHei是 Windows 字体WenQuanYi Micro Hei是 Linux 常见中文字体。这一段字体栈可以让三大桌面平台都有合适的中文兜底但如果目标是移动端通常还需要补充system-ui或具体平台字体名。6.2 font-display 加载策略font-display决定字体文件加载期间和加载失败后的渲染行为。它有五个取值实际项目中建议这样选取值行为适用场景auto由浏览器决定通常等同 block不推荐行为不一致block最多等待 3 秒期间不显示文字Logo、关键视觉swap先显示兜底字体字体加载完后换回正文推荐体验最稳fallback短时间等待后一直使用兜底字体对字体风格要求较低optional非常短地等待弱网下直接不加载性能敏感场景正文推荐swap。这样即使 Knora One 的 WOFF2 文件体积较大或者加载很慢用户也能先看到系统字体渲染的文字不会出现长时间白屏。对品牌标题等强视觉场景才考虑使用block。6.3 unicode-range 分段加载可选如果项目里的 Knora One 字体文件较大可以按 Unicode 区块拆分字体子集使用unicode-range触发浏览器按需下载font-face { font-family: Knora One; src: url(./fonts/KnoraOne-CJK.woff2) format(woff2); font-weight: 400; unicode-range: U4E00-9FFF; } font-face { font-family: Knora One; src: url(./fonts/KnoraOne-Latin.woff2) format(woff2); font-weight: 400; unicode-range: U0000-00FF; }注意这是有额外前置条件的你使用的 Knora One 发布包必须提供分块子集文件比如KnoraOne-CJK.woff2而不是只有一个完整字体文件。如果发布包没有分块这段配置无法生效。同时要注意如果项目还使用非 BMP 平面字符比如扩展 B 区的生僻字只写U4E00-9FFF会导致这些字符永远走系统兜底。字体回退在 Unicode 分区层面的逻辑在需要覆盖扩展区字符时尤其复杂建议先在测试页面里验证所有目标字符的渲染情况再上生产。7. 字体兜底功能测试与效果验证配置完成后必须在浏览器里做真实渲染验证。测试页面要覆盖普通中文、冷门标点、生僻汉字、多语言混排、拉丁字符、数字与全角符号、以及断网场景。7.1 创建一个测试页面在项目目录下创建index.html!DOCTYPE html html langzh-CN head meta charsetUTF-8 meta nameviewport contentwidthdevice-width, initial-scale1.0 titleKnora One 字体兜底功能演示/title link relstylesheet href./style.css /head body h1Knora One 字体兜底演示/h1 section classtest-block h21. 常见中文段落/h2 p字体是整个页面视觉的基础。使用开源中文字体时需要考虑字符覆盖范围和加载性能。/p /section section classtest-block h22. 生僻字与扩充区字符/h2 p龘靐齉爩鱻麤龗灪/p /section section classtest-block h23. 全角与半角标点/h2 p中文逗号句号。英文逗号, 句号.(半角) 全角括号/p /section section classtest-block h24. 数字与拉丁字母/h2 p1234567890 ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz/p /section section classtest-block h25. 多语言混排/h2 p日文仮名あいうえお かきくけこ/p p韩文音节가나다라마바사아자차카타파하/p p英文与中文混排这是 OpenType 字体特性测试。/p /section /body /html在浏览器中直接双击打开index.html或者用本地静态服务器启动。推荐用后者避免file://协议带来的字体加载限制# Python 自带静态服务器在项目根目录执行 python -m http.server 8080然后访问http://127.0.0.1:8080。7.2 第 1 步确认字体加载成功打开 DevTools 的 Network 面板刷新页面。过滤Font资源类型可以看到KnoraOne-Regular.woff2和KnoraOne-Bold.woff2的加载请求。状态码应为 200Size 不为(from disk cache)也需要小于字体文件本身大小。如果 Font 资源是 404检查 CSS 里font-face的src路径以及服务器启动目录。7.3 第 2 步检查生僻字是否渲染观察测试页面第 2 节。生僻字“龘靐齉爩鱻麤龗灪”在 Knora One 中很可能没有全部覆盖所以实际渲染时部分字符会落到后面的系统字体上。这里要做的不是“换一个更大的字体”而是确认兜底字体是否真的接住了这些字符。打开 DevTools 的 Elements 面板选中生僻字所在段落在 Computed 标签页中查看font-family的计算值你会发现浏览器计算出来的字体并不等于你写在 CSS 里的完整列表而是最终实际用于渲染的字体名。如果看到字体不是 Knora One而是苹方或微软雅黑说明兜底链生效了。7.4 第 3 步多语言混排的兜底行为日文假名和韩文音节一般不在 Knora One 的覆盖范围内所以页面第 5 节在日文和韩文段落中浏览器会自动跳转到系统日文字体或韩文字体。这是正常现象并不代表字体坏了。我们可以用这个现象判断兜底链是否足够宽。如果这段文字在浏览器里出现方块说明系统字体兜底也没接住或者当前系统缺少基本 CJK 字体。Linux 无桌面环境的服务器上这类问题尤其明显但演示用的桌面系统一般不会出现。7.5 第 4 步模拟字体加载失败在 DevTools 的 Network 面板勾选 Offline或者手动停用 project 下的字体请求模拟字体加载失败。此时整个页面应该仍然可以阅读因为font-display: swap会让浏览器直接使用font-family列表里的第二个字体。这是字体兜底最核心的价值主字体挂了页面文字不能挂。验证通过的标准是页面上没有任何一个测试字符变成方框。7.6 第 5 步对比不同字体栈配置为了更直观地看出字体栈顺序的影响临时把 CSS 改成这样再刷新对比body { font-family: Knora One, sans-serif; }这时如果 Knora One 缺字浏览器就会直接跳到sans-serif这个通用字体渲染效果往往不可预测甚至可能直接使用系统默认的“宋体”风格或不可控的界面字体。这个对比能直观说明font-family里不能只写一个字体加一个sans-serif就完事中文字体栈需要尽量把主流的系统字体按平台填进去。8. 自动化字形检测脚本页面手工验证只能覆盖测试页面列出字符上线后仍然可能出现漏网字符。更可靠的方案是用 Python fontTools 写一个缺字检测脚本在 CI 或发布前自动检查字体文件是否覆盖了项目代码中的全部文本。以下是脚本示例输入一个文本文件输出字体文件中缺失的字符列表from fontTools.ttLib import TTFont import sys def get_text_from_file(filepath: str) - str: with open(filepath, r, encodingutf-8) as f: return f.read() def check_coverage(font_path: str, text: str): font TTFont(font_path) cmap font.getBestCmap() missing [] for ch in set(text): if ch \n or ch : continue if ord(ch) not in cmap: missing.append(ch) if missing: print(f发现 {len(missing)} 个字符不在字体中) for ch in sorted(missing, keylambda c: ord(c)): print(f U{ord(ch):04X} {ch}) else: print(所有字符均被字体覆盖。) if __name__ __main__: if len(sys.argv) ! 3: print(用法: python check_coverage.py font.ttf text_file) sys.exit(1) font_path sys.argv[1] text_file sys.argv[2] text get_text_from_file(text_file) check_coverage(font_path, text)运行时先生成项目所有文本内容比如从源码中提取中文文案保存到all_text.txt再执行python check_coverage.py ./fonts/KnoraOne-Regular.ttf ./all_text.txt输出的结果是判断 Knora One 是否覆盖所有文本字符的客观标准。如果发现缺失有两种选择单独为缺失字符配置另一款的字体或者接受缺失并依赖系统字体兜底。自动化脚本的作用是让你从“上线前肉眼检查”变成“提交前机器检查”在 CI 里甚至可以加一个失败条件缺失字符数超过阈值就阻止合并。注意这里的检测结果基于字体文件里的cmap表直接反映字体能渲染哪些 Unicode 码位结果可靠但不会反映字体造型在样式上是否协调后者仍需人工判断。9. 资源占用与加载性能观察网络字体的性能问题在中文项目中比英文字体更突出。英文常用字体文件一般只有几十 KB中文字体因为包含数千个常用汉字字形体积动辄几 MB 到十几 MB加载耗时是必须关注的点。在 DevTools 的 Network 面板中可以查看KnoraOne-Regular.woff2的传输大小和加载时间。如果项目引入的是完整 TTF 而不是 WOFF2文件体积可能更大。WOFF2 是压缩后的 Web 字体格式通常比 TTF 小 30% 到 50%所以如果发布包同时提供了 WOFF2Web 端优先用 WOFF2。字体加载有两种主要优化手段。一种是子集化把字体按unicode-range拆分成多个小文件浏览器只下载页面实际用到的字符区块。另一种是减少字重数量正文只引入 400 和 700 两个字重避免把 100 到 900 的全部字重都嵌入页面。对于大公司官网、内容型产品建议在构建阶段做字体子集化对个人项目至少保证主字体是 WOFF2 格式。从内存角度字体文件在渲染时会被解码并加载到内存中中文字体占用的内存比英文字体更大。客户端应用的性能观察方法可以用系统自带的任务管理器或活动监视器观察进程内存但字体加载不是持续占用内存大户它不是主要瓶颈。前端页面更应关注的是网络耗时而不是运行时内存。对比数据时需要在同一网络环境下做“开启字体”和“关闭字体”两组测量记录首屏文本渲染时间两组差异能直观看出字体加载对首屏的影响。10. 常见问题与排查方法问题现象可能原因排查方式解决方案页面文字全部显示方框系统缺少中文字体或字体回退链全部失配DevTools Elements 中查看计算字体在字体栈末尾补充通用字体和中文字体字体文件加载 404font-face 的 src 路径错误Network 面板查看请求 URL按 CSS 文件相对位置修正路径生僻字时有时无主字体缺字兜底字体也缺同一个字用 fontTools 脚本检查字符覆盖增加覆盖该字符的字体或在系统中安装大字符集字体首屏文字空白font-display 设为 block 或 auto且字体加载慢Network 面板查看字体加载耗时正文改为 font-display: swap日文/韩文显示为方块字体栈未提供对应语言字体检查系统是否安装对应语言字体字体栈补充系统日韩字体或在系统安装语言包同一页面不同设备渲染差异大字体栈中系统字体在各平台不同在 Windows/macOS/Linux 分别截图对比接受差异明确 UI 规范中的平台字体映射安装字体后页面仍使用旧字体浏览器缓存了旧的字体链表强制刷新或清除浏览器缓存CtrlF5 强制刷新检查 Network 面板中的加载来源网页字体闪一下再替换font-display: swap 的预期行为无需排查需要调整期望这是保证可读性的设计这 8 个问题覆盖了最常见的字体兜底故障。实际项目中出现字体问题先不要急着换字体先分三步排查先确认字体文件有没有加载成功再确认字体文件里有没有目标字符最后确认字体栈顺序和font-display策略。多数问题在这三步里就能定位。11. 最佳实践与使用建议从这次演示中可以总结出几条工程化建议直接用于项目实践。第一字体栈一定要按“主字体 平台中文字体 通用字体”三层设计。不要把sans-serif作为兜底主力因为通用字体的具体字形由浏览器自己决定不可控。推荐把 Windows 的微软雅黑、macOS 的苹方、Linux 的文泉驿微米黑都显式写进字体栈。第二文件命名和目录结构要统一。字体文件统一放在assets/fonts/下文件名带字重和后缀例如KnoraOne-Regular.woff2、KnoraOne-Bold.woff2。不要出现最终版.ttf、new2.woff2这类命名否则后端清理缓存或打包发布时极易出错。第三发布前运行缺字检测脚本。将项目中所有页面文本提取到文本文件用 fontTools 做字形覆盖检测。这个动作应该集成到 CI 中作为字体发布的前置检查。如果缺失字符较多要么换字体要么把关键文案中的生僻字统一替换为常见字或者设计“提示输入框”等 UI 层面不依赖长文本的场景。第四涉及商用项目字体授权不能只看“可以免费下载”。开源字体也必须保留授权文件修改后需要按协议更名。字体文件不能通过 CDN 直接引用未授权的第三方字体资源这属于直接的版权风险。团队内部需要规范字体选型清单记录授权协议版本方便法务或采购随时查证。第五多语言场景不要只靠 CSS 字体栈硬扛。如果产品包含中文、日文、韩文、泰文等最好在系统层面或设计层面为每种语言单独指定首选字体而不要让字体栈一家一家去试试出来的字形组合在美观度上往往不可控。字体兜底解决的是“能显示”不负责“好看”。第六界面正文优先使用系统字体作为主字体把自定义字体用在品牌标题等重点位置是最稳的组合。尤其对内容型产品正文阅读量大系统字体在字重、行距、渲染引擎上的适配往往比自定义字体更成熟。自定义字体更适合 300 字以内的短文案。第七在弱网场景下建议用font-display: optional搭配系统字体做正文。这样字体加载优先级低网络差时直接跳过页面显得不那么“慢”。网络条件改善后浏览器会自动加载字体。这个策略在面向普通用户的内容站点上体验最优。12. 总结与下一步这次以 Knora One 开源中文字体为演示对象把字体兜底机制的完整链路过了一遍字体安装、CSS 回退链配置、font-display 加载策略、浏览器验证、fontTools 缺字检测、性能观察和问题排查。核心结论是字体兜底不是一行font-family的事而是一个从字体选择、加载控制到自动化检测的工程体系。如果你现在要在一个真实项目里用 Knora One建议按这个顺序做先下载官方字体包确认授权协议把字体文件放进项目写好font-face和字体栈部署一个测试页面验证普通中文、生僻字、多语言、离线场景四个维度的表现再用 fontTools 脚本把项目文本过一遍确认缺字数量在可控范围内最后把检测脚本加到 CI 流程里防止以后新增文案时把缺字问题带回项目。最容易踩的坑有三个font-face路径写错导致字体根本没加载、字体栈只写了sans-serif兜底导致字体选择不可控、以及忽略font-display导致弱网首屏空白。这三个坑都可以通过 DevTools 和本地测试页面提前发现。后续可以扩展的方向包括把 Knora One 拆分成更细的unicode-range子集配合打包工具自动生成子集文件在团队内搭建字体管理平台统一管理授权协议和版本如果字体本身提供了可变字重能力还可以研究一下用可变字体属性减少文件体积。字体兜底这件事越早纳入工程规范后期排错的成本就越低。
返回列表