企业官网建设流程全解析

有人把一份图表 PDF 甩给我，说下游那边回话了：图里的中文标题得换成黑体GB2312。我打开一看，文件里用的确实是黑体，问题根本不在字体选得对不对，而在 R 导出的那一刻，PDF 里压根没把中文字形嵌进去，阅读器是靠本地字体凑出来显示的，换台机器就全变样。这两年因为做图交付踩过的字体坑不少，我干脆把两件事摊开讲清楚：一是黑体GB2312和普通黑体到底差在哪，二是 R 语言往 PDF 里输出中文时，为什么换个字体就翻车、以及怎么一次性配好。

如果你只是偶尔用 R 画个图存成 PNG，可能从来没遇到这个问题，因为位图设备走的是系统渲染，中文字体随手可得。但只要目标格式是 PDF，尤其是要交给印刷、投稿、归档的场景，字体嵌入就是绕不过去的一道坎。这篇内容适合三类人看：经常用 R 出图但没系统研究过字体机制的、被要求"统一用某某字体"却不知道差别在哪的、以及交付 PDF 之后被人反馈"打不开""字变了"想搞清楚原因的。下面从字体本身讲起，一路讲到能直接抄的配置和排查链路。

1. 黑体GB2312和普通黑体，差的不是字形设计而是字符清单

1.1 GB2312 是一份 1980 年定下的收字范围

很多人以为"黑体GB2312"是某种特殊的黑体设计，其实不是。GB2312 是一份字符集标准，规定了这套字体要覆盖哪些字，而不是规定字长什么样。它收录了 6763 个汉字，其中一级汉字 3755 个按拼音排序，二级汉字 3008 个按部首排序，另外还有 682 个非汉字图形符号，加起来一共 7445 个码位。这个规模放到今天看是偏小的，但它诞生在上世纪八十年代，当时的存储介质和内存都极其紧张，能装下七千多个字形已经是很重的负担。

字库厂商按字符集切版本，纯粹是被存储逼出来的。一个汉字字形要存轮廓控制点、要存度量信息，字符越多文件越大。于是同一套设计会拆成好几个文件卖：只含 GB2312 范围的精简版、覆盖 GBK 的完整版、再往后还有覆盖 GB18030 的超大版本。你在字体名里看到的那个 GB2312 后缀，本质上是"这个文件只装了七千多个字"的声明，跟笔画风格没有必然联系。

有意思的是，正因为它是精简版，反而保留了一些原始设计的味道。后来扩充到 GBK 的版本要补进去一万四千多个新字形，补字的工作横跨很多年，参与的人也换过好几拨，补出来的字跟老字之间难免有风格裂缝。你在同一行字里看到某个字突然偏瘦、偏大或者重心偏上，多半就是补字补出来的。

1.2 补字带来的风格裂缝具体长什么样

说"风格裂缝"有点抽象，落到实际的视觉上，主要体现在三个地方。第一是字面率，也就是字形实际占的那块面积相对于字身框的比例。GB2312 版的原生字形大多是在铅字和照排字基础上数字化的，字面偏小、四周留白多，一排字看过去呼吸感比较强。GBK 版补进来的字为了在同样字号下不显得太小，往往会稍微放大字面，混排的时候就会出现"有的字胖有的字瘦"。

第二是笔画粗细的比例。传统黑体的横竖笔画粗细比控制得比较克制，横画比竖画略细但差距不大，整体显得端庄。补字阶段有些字形参考了不同的样本，横竖比例会跑偏，个别字看起来发飘或者发闷。第三是重心高度，原生字形重心普遍偏上一点，补字的重心位置如果没有严格对齐，整行字排下来就会有上下起伏的感觉。

这些差异在单看一两个字的时候几乎察觉不到，但一旦排成整段文字，或者做成图表里的坐标轴标签、图例，差异就会被放大。尤其是需要中英文和数字混排的场合，风格不统一会显得很业余。所以如果你做的是正式交付物，字体版本的选择其实比字体族的选择更值得较真。

1.3 西文和标点是最容易露馅的部分

判断一个黑体是哪个版本，看汉字其实不够快，看西文字母和数字最直接。GB2312 时代的黑体，西文部分往往是等宽设计，字母和数字占的宽度基本一致，字符造型偏窄偏瘦，有些数字比如"1"没有底横，看起来像一根竖线加个小斜撇。这种设计在表格对齐上有优势，但跟现代无衬线西文字体放在一起就明显不搭。

扩充版本大多把西文改成了比例宽度，字母"i"和"m"占的宽度不一样，整体更接近常见的西文无衬线字体，中英混排的时候视觉节奏更自然。同时数字的造型也会调整，"1"加上底横、"4"改成开口或者闭口，这些都是很细但很显眼的差别。

标点的问题更隐蔽也更麻烦。全角标点的字面宽度、位置高低在两个版本里可能不同，逗号句号在字身框里的位置差一点点，排成两端对齐的段落时，行末的标点就会对不齐，出现参差不齐的毛边。做中文排版的人对这个特别敏感，一张图里如果标点高低不一，专业感立刻掉一档。

1.4 三分钟分辨：拿生僻字做缺字测试

想快速确认手上的字体到底是 GB2312 版还是覆盖更广的版本，最直接的办法是拿几个不在 GB2312 范围内的字去渲染，看能不能正常显示。这几个字可以记一下：喆、堃、昇、赟、镕。它们都在 GBK 里，但都不在 GB2312 的 6763 个汉字之内。如果换成 GB2312 版字体，这几个字要么直接消失，要么变成空白或者方框。

用 R 做这个测试很快，把字渲染出来看一眼就行：

probe <- c("喆", "堃", "昇", "赟", "镕", "正常字") cairo_pdf("probe.pdf", width = 6, height = 2, family = "SimHei") par(mar = c(0, 0, 0, 0)) plot.new() text(0.5, 0.6, paste(probe, collapse = " "), cex = 3, family = "SimHei") dev.off()

更严谨一点的做法是直接读字体文件的字符映射表，数一数里面有多少个字形。这个用 Python 的 fontTools 库几行就能搞定，不需要装 R 包：

from fontTools.ttLib import TTFont f = TTFont("simhei.ttf") cmap = f.getBestCmap() print("字形数:", len(cmap)) print("是否包含喆:", ord("喆") in cmap) print("是否包含堃:", ord("堃") in cmap)

七千多说明是 GB2312 级别的子集，两万多说明覆盖到 GBK，再往上就是更大范围的版本。这个方法比目测靠谱，交付之前扫一遍，能提前把缺字问题挡在门外。

2. R 的 pdf() 为什么天生不认中文

2.1 标准 14 字体和 ISOLatin1 编码的天花板

PDF 规范里定义了十四款"标准字体"，包括几款西文衬线、无衬线、等宽字体以及符号字体，它们的共同点是阅读器内置了度量信息，文件里不需要嵌入字形就能正常显示。R 的 pdf() 设备默认就是围绕这套机制设计的，它把文本按 ISOLatin1 编码写进去，引用这十四款字体之一。

问题就出在这里：这套字体里没有一个汉字。当中文文本送进 pdf() 的时候，编码转换这一步就已经把字符处理掉了，根本轮不到字体匹配。你看到的空白、问号、或者干脆什么都没有，都是在这一层就出了事，后面再怎么调字体参数也无济于事。

很多人第一次遇到这个情况会以为是自己字体没装，跑去装了一堆中文字体，结果毫无变化。原因很简单，pdf() 压根不去系统里找字体，它查的是 R 内部的一套字体度量数据库，那套数据库里只有配套的西文字体信息。理解这一点，后面所有的方案选择就都能想通了。

2.2 四种失败长相，对应四种不同的病因

出问题的时候，屏幕上呈现的样子其实是有信息量的，不同的表现指向完全不同的原因。我整理了一张对照表，遇到问题先对号入座，能省掉大量瞎试的时间。

第一种最容易被误判成"中文没写进去"，其实文本对象是在的，只是引用了一款没有汉字的字体，阅读器找不到字形就画了个空白。第二种常出现在生僻字上，字体本身能用，但那个字不在它的字符集里，这就跟上一节讲的 GB2312 边界直接相关了。第三种和第四种现在少一些，因为 R 从 4.0 之后默认走 UTF-8，老代码迁移过来的时候才容易撞上。

2.3 family 参数查的不是系统字体

这是最反直觉的一点。你在 pdf() 里写 family = "SimHei"，以为它会去系统字体目录里找这个字体，实际上它做的是在 R 的字体映射表里查这个名字。查不到，它不会报错，而是安安静静地退回默认字体，然后你的中文就全部消失了。这种"静默失败"是最坑人的，因为没有任何提示，你只会觉得"怎么什么都没画出来"。

R 里跟字体相关的参数其实有三层。最外层是设备函数上的 family，决定默认字体族；中间层是 par(family = ...) 或者单个绘图函数的 family 参数，可以在一次绘图里临时切换；最内层是 grid 和 ggplot2 那一套，用 gpar 或者 theme 里的 family 指定，最终还是会传给底层设备。三层名字不一样，但最后都落到同一个地方：设备能不能找到并嵌入这个字体。

理解了这层，你就明白为什么有些教程里写 pdf(family = "GB1") 能出中文，有些又写必须用 cairo_pdf。它们走的是完全不同的机制，前者用的是 PDF 的 CID 字体引用，后者用的是真正的字形嵌入，行为自然不一样。

2.4 图形窗口能看、导出就坏的原因

还有一种情况特别让人抓狂：在 R 的图形窗口里预览，中文显示得好好的，一导出 PDF 就全没了。这不是玄学，因为屏幕设备和文件设备用的是两套完全不同的渲染后端。屏幕设备直接调用操作系统的图形接口，系统里有什么字体就能用什么字体；文件设备要自己处理字形嵌入和编码，两边的能力根本不对等。

在集成开发环境里点"导出"按钮，走的又是第三个后端，可能跟命令行里跑出来的结果都不一样。所以判断中文能不能正常输出，永远要以最终文件为准，不能看预览窗口。这个习惯我建议早点养成，能避免大量无效调试。

3. 四条把中文塞进 PDF 的路线，各自的代价

3.1 cairo_pdf：目前最省心的主线方案

cairo_pdf() 是 R 里少数几个真正能正确处理中文的 PDF 设备，它背后是一个成熟的图形库，通过系统的字体服务去查找字体，找到之后把用到的字形子集提取出来嵌进 PDF 文件。这样生成的文件，换任何一台机器打开，显示效果都是一致的，文本还能被选中、被搜索、被复制。

用法上没什么花哨的，把文件名、尺寸、字体族传进去就行：

cairo_pdf("chart.pdf", width = 7, height = 5, family = "SimHei") plot(1:10, main = "中文标题", xlab = "横轴", ylab = "纵轴") dev.off()

它的优势在于跟 ggplot2 配合得很自然，theme 里指定的字体族能一路传到设备层，不需要额外做转换。文件体积也控制得不错，因为只嵌入实际用到的字形子集，不是整个字体文件。缺点主要有两个：一是字体名字必须跟系统里注册的名字对上，写错了就静默回退；二是在某些精简环境里，R 编译时可能没带图形库支持，cairo_pdf 会不可用，需要先确认一下。

3.2 showtext：跨设备一致，代价是文字变成图形

showtext 走的是完全不同的路子。它把字体文件读进来，用字形解析库拿到每个字的轮廓，然后在 R 的绘图层面上把文字当成多边形路径画出来。因为最终画的是路径而不是文本对象，所以不管什么设备、什么编码，出来的结果都一模一样，彻底绕开了字体嵌入这一整套麻烦。

配置起来也不算复杂，注册字体、打开自动模式，之后所有绘图都会走它：

library(showtext) font_add("heiti", regular = "C:/Windows/Fonts/simhei.ttf") showtext_auto() cairo_pdf("chart_showtext.pdf", width = 7, height = 5) plot(1:10, main = "中文标题", family = "heiti") dev.off() showtext_auto(FALSE)

代价也很明确：PDF 里没有文本对象了，文字变成了一堆矢量路径。这意味着文件里的中文不可搜索、不可复制、不可编辑，做无障碍阅读或者文本提取的场合直接不合格。文件体积也会明显变大，因为每个字形都要存一遍路径数据。字号特别小的时候，路径渲染还可能出现轻微的毛刺或者粗细不均，用在正式印刷品上需要放大检查。

我的判断标准是这样的：如果这份 PDF 只是给人看，不需要检索和编辑，showtext 很稳；如果下游要做文本抽取、要过预检、要给人改稿，那就老老实实用 cairo_pdf。另外 showtext 在批量出图时有个小坑，字体注册是一次性的，如果脚本里反复打开关闭自动模式，容易出现某些图没走到它的情况，建议在脚本开头统一打开，结尾统一关闭。

3.3 pdf(family = "GB1")：不嵌字体的老路子

这是一条有年头的方案，原理是往 PDF 里写一个字体引用，指明使用某个中文 CID 字体族，配合对应的编码表，让阅读器自己去本地找字体来渲染。文件体积极小，因为一个字形都没嵌进去，早年间网络慢、存储贵的时候这是个很实用的折中。

现在的实际问题在于，这套机制高度依赖阅读器。某些阅读器内置了对应的字体资源，能正常显示；换一个就变成空白或者乱码；印刷厂的预检工具更是直接判不合格，因为它检查的就是字体有没有嵌入。所以这条路我只在一种情况下考虑：对方明确说了环境里装了对应字体、并且只看不印。

3.4 extrafont 与 Type1 转换：历史包袱

还有一条路是把系统里的 TrueType 字体转成 Type1 格式，生成配套的度量文件和轮廓文件，再注册给 pdf() 使用。这条路能实现真正的嵌入，在 cairo 支持不完善的年代是主流做法。

问题是流程太长：要装字体转换工具，要装 PostScript 解释器，转换过程对字体集合格式的支持不好，碰到 TTC 这种打包了多个字重的文件经常失败，转出来的字形偶尔还会有细微变形。转换一次要花不少时间，字体更新了还得重来。新项目我完全不推荐走这条路，除非你维护的是十年前的老脚本，改动成本太高。

四条路线的关键差异整理成一张表，选型的时候对着看：

4. 一份能直接抄的配置：从字体体检到导出验证

4.1 第一步永远是体检：字体在不在、叫什么名

配置之前先确认两件事：系统里有没有这个字体文件，以及它在字体服务里注册的名字是什么。这两件事经常不一致，文件名叫 simhei.ttf，注册名可能是 SimHei，界面上显示的中文名又是"黑体"，三个名字混着用，很容易配错。

在 R 里查最方便，装一个专门做字体匹配的包，一行就能列出来：

library(systemfonts) all_fonts <- system_fonts() hit <- subset(all_fonts, grepl("Hei|hei|黑", family)) hit[, c("family", "style", "path")]

输出的 family 列就是你要填进绘图代码的名字。Linux 和 macOS 上还可以在命令行用字体查询工具，能看到字体覆盖的字符范围，确认一下有没有中文字形。Windows 上字体文件基本都在系统字体目录下，路径是固定的。

有个细节值得注意：同一个字体在不同系统上的注册名可能不一样。同是一款黑体，在一个系统上叫 SimHei，在另一个系统上可能被识别成拼音全称或者中文名。所以跨平台脚本里最好把候选名字列成一个向量，逐个尝试匹配，别硬编码一个名字。

4.2 基础图形的最小可用版本

确认了字体名之后，基础绘图系统改起来很简单，把设备函数上的 family 换掉就行。这里要注意的是，family 只是设了默认值，如果某个绘图函数自己带了 family 参数，会覆盖掉设备级的设置，两边不一致的时候容易出现"标题是中文正常、坐标轴标签却挂了"的诡异现象。

cairo_pdf("base_plot.pdf", width = 7, height = 5, family = "SimHei", pointsize = 11) par(mar = c(4.5, 4.5, 3, 1.5), las = 1) plot(1:10, main = "中文标题测试", xlab = "横轴标签", ylab = "纵轴标签", family = "SimHei") dev.off()

pointsize 这个参数容易被忽略，它决定了设备里"1 个单位字号"对应多大。基础图形的 cex 是相对这个值的倍数，改了 pointsize，所有元素的绝对大小都会跟着变，原来调好的边距可能就不够了。中文的字身框比西文饱满，同样的字号看起来更"满"，所以从西文换成中文之后，边距通常要适当放大一点。

4.3 ggplot2 的写法：theme 与导出设备必须对齐

ggplot2 有自己的字体体系，用 theme 里的 base_family 统一设置，或者在具体的 text 元素上单独指定。麻烦的地方在于导出环节，很多人 theme 配得好好的，用保存函数一存又坏了，原因就是保存函数选错了设备。

library(ggplot2) p <- ggplot(mtcars, aes(wt, mpg)) + geom_point(color = "#3b6ea5", size = 2) + labs(title = "中文标题", x = "重量", y = "油耗") + theme_bw(base_size = 11, base_family = "SimHei") + theme(plot.title = element_text(family = "SimHei", face = "plain")) ggsave("gg_plot.pdf", p, width = 7, height = 5, device = cairo_pdf)

关键就在最后那个 device 参数。保存函数默认会根据文件扩展名去猜设备，猜出来的是普通的 pdf 设备，也就是前面说的那个不认中文的家伙。必须显式指定成能处理字体的设备，theme 里的配置才真正生效。这个坑我踩过不止一次，症状就是预览窗口里一切正常，存出来的文件里中文全没了。

4.4 字号、字重和行距的微调经验

中文排版和西文排版的度量习惯差别不小，直接套用西文的参数往往不好看。字号方面，同样标称 11 磅，中文字形占的面积明显更大，视觉上会比西文重一档，图表里的字号可以比纯西文场景小半号到一号。行距方面，中文的推荐行距普遍在字号的 1.3 到 1.5 倍之间，而西文常用 1.2 倍，多行中文如果按西文的行距排，会显得非常拥挤，字与字之间几乎没有呼吸空间。

在 ggplot2 里控制行距用 lineheight 参数，基础图形系统里没有直接对应的开关，只能靠调整位置或者拆成多次绘制来实现：

theme(plot.title = element_text(lineheight = 1.4)) theme(axis.text = element_text(lineheight = 1.2))

字重是另一个雷区。很多中文字体只提供一个常规字重，没有独立的粗体文件。当你把字体样式设成粗体的时候，渲染层可能会做"伪加粗"，把字形轮廓整体外扩一点点来模拟。小字号下这种做法看起来还行，放大到印刷尺寸就会发现笔画粘连、糊成一团，尤其是笔画密集的字。稳妥的做法是尽量不用伪粗体，需要强调的时候靠字号、颜色、留白来区分，而不是靠加粗。

4.5 导出后回验：别信预览，看嵌入状态

文件生成之后，最后一步是验证。最直接的办法是用 PDF 分析工具查一下字体嵌入情况，命令行工具就能做，输出一张表，列出每个字体、类型、是否嵌入、是否子集化。

pdffonts chart.pdf

看两列就够了：嵌入那一列是不是 yes，子集那一列是不是 yes。全是 yes 说明字形已经打进文件里，换机器打开不会变。如果嵌入是 no，说明走的还是引用路线，得回头换方案。如果压根没列出中文字体，那说明中文根本没被当成文本写进去，可能是编码阶段就丢了，或者被转成了路径。

我一般还会做一次"换机测试"，把文件发到另一台设备上打开看一眼。听起来笨，但这是唯一能确认实际效果的办法，工具报告和真实渲染偶尔会有出入。

5. 真实排查链：从满屏方框到正常出图

5.1 第一层：中文全部空白，西文完全正常

这是最常见的起点，症状很典型：图表的结构、坐标轴、刻度数字全都正常，唯独中文的部分是空的，像被人擦掉了一样。看到这个现象，基本可以直接判定是字体没匹配上，文本对象是存在的，只是引用了一款没有汉字的字体。

排查顺序是这样：先确认用的设备是不是支持字体嵌入的，如果是普通 pdf 设备，问题到这一步就结束了，换设备即可；如果已经用了支持嵌入的设备，那就去查字体名字对不对，把绘图代码里写的名字和字体服务里注册的名字逐字符比对一遍，注意大小写、注意是不是用了中文名而系统只认英文名。

这一步还有一个容易忽略的点：字体名字写对了，但字体文件本身损坏或者是个零字节的占位文件，也会表现成一样的效果。检查一下字体文件的路径能不能正常读取，文件大小是不是合理，能排除掉一批莫名其妙的情况。

5.2 第二层：大部分字正常，个别人名地名消失

字能显示出来了，但某些特定的字不见了，或者变成了空心方框。这个现象直接把矛头指向字符集覆盖范围，也就是前面讲的第一节内容。最典型的场景是图表里要标注样本名称、地名、人名，里面夹了一两个生僻字，正好落在 GB2312 的边界之外。

我的处理办法是分两步走。第一步先定位，把图表里所有要显示的字符串提取出来，逐个字符跟字体的字符映射表比对，把缺的字列成清单。第二步再决定策略：如果缺的字很少，可以换一款覆盖更广的同族字体；如果必须保持字体族一致，那就得接受这几个字用替代字体渲染，或者干脆改成图片形式绕过去。

这里有个很实用的习惯：做交付之前把整份图表里出现的所有中文文本跑一遍缺字扫描，别等到对方反馈了才发现。扫描脚本很简单，把字符串拆成单字，逐个查字符映射表，缺的打印出来。

5.3 第三层：字出来了，但粗细不对、边缘发糊

字形完整了，但视觉上不对劲：笔画该细的地方糊在一起，密集的字像一团墨。这种情况多数是伪粗体导致的，也可能是字体本身在小字号下的渲染优化不好。伪粗体的原理是把轮廓向外偏移一点再填充，偏移量固定的话，笔画密的地方就会互相侵占。

判断方法很简单，把同一段文字用常规字重和加粗各渲染一遍，放大到 400% 对比。如果加粗版本的笔画末端出现了不自然的圆头或者毛刺，基本就是合成的假粗体。处理方式有三种：换一款真的有独立粗体文件的字体族、放弃加粗改用其他强调手段、或者接受它在小字号下不显示粗体。

还有一种发糊是分辨率或者渲染参数导致的，尤其是在把位图转成 PDF 嵌入的时候，原始位图分辨率不够，放大之后就糊了。这种情况要回到源头，提高出图时的分辨率参数，而不是在 PDF 层面想办法。

5.4 第四层：本地看着好，别人打开就变样

最让人难受的一类问题，自己机器上一切正常，发给别人打开，字体全变了，或者部分文字变成了别的字形。这不是文件坏了，是字体没有被完整嵌入，阅读器用了本地的替代字体来渲染。

验证方法前面说过，用字体分析工具查嵌入状态。处理方式是换成真正嵌入字形的设备重新导出。有一种情况需要额外注意：某些工具在嵌入时会做子集化，只保留用到的字形，如果后续有人要在 PDF 里编辑文字、补充新字，会发现新字显示不出来，因为子集里没有。做需要二次编辑的交付物时，要考虑是不是关掉子集化，代价是文件会变大不少。

6. 什么情况下才该主动选 GB2312 版黑体

6.1 下游流程锁死了字符集

有一种情况是没得选的：下游的排版系统、印刷流程、或者归档规范明确要求使用某个字符集范围内的字体。这种约束通常来自很老的系统，它的编码处理能力有限，超出范围的字符可能直接导致整份文件处理失败。遇到这种要求，别去争论字体好不好看，先满足兼容性，把这当成一个工程约束来对待。

判断是不是真的受限于字符集，可以做一个简单测试：拿一份含生僻字的文档走一遍下游流程，看是报错、是丢字、还是正常。如果丢字了但没报错，说明系统能吞下去但不认识；如果直接报错，说明连编码层都过不去。这两种情况的处理策略不一样，前者可以在源头做字符替换，后者必须换字体。

6.2 追求特定年代的版面味道

还有一种是主动选择，做书籍封面、复古风格的海报、或者需要某种年代感的版式设计时，GB2312 版黑体那种偏小字面、偏窄西文、重心略高的特征，反而能营造出一种特定的气质。这种时候选的不是字符覆盖范围，是它的造型语言。

不过要提醒一句，这种选择必须建立在内容可控的前提下。如果版式里有大量不确定的文本内容，比如用户生成的内容、外部导入的数据，那用窄字符集的字体就是在给自己埋雷，随时可能因为一个生僻字破版。

6.3 我的取舍：默认用覆盖广的版本，交付前做缺字扫描

说点个人经验。我现在做图表交付，默认选覆盖范围广的字体版本，把兼容性放在造型之前。理由很实际：字体造型的差异，除了专业排版的人，几乎没人会注意到；但少了一个字，所有人一眼就能看见，而且会直接质疑你的专业度。

在这个前提下，如果确实需要 GB2312 版本的造型，我会采用双字体策略：正文和大部分标签用覆盖广的版本保证不出错，只有在确定的、内容可控的标题或者装饰性文字上，才用 GB2312 版本去追求那个味道。这样既拿到了想要的视觉效果，又不会因为个别字翻车。

最后分享一个我反复用的小流程：出图脚本里固定加一段字体预检，把这次要渲染的所有字符串收集起来，逐字比对目标字体的字符映射表，缺字就打印警告并终止。这段代码不到二十行，但帮我挡掉了至少五六次交付事故。花半小时把这道闸门装好，比事后一封封解释邮件划算得多。