企业官网建设流程全解析

简介：这份资源面向在 Ubuntu 系统下使用 WPS 办公软件、却频繁遭遇字体缺失提示的用户，尤其是需要处理含特殊符号文档的办公与排版人群。当 WPS 弹出缺少 Symbol、Wingdings、Wingdings 2、Wingdings 3 等字体的警告时，文档中的符号与图形往往显示为问号或空缺，该字体集正是为补齐这一短板而整理。压缩包共收录 129 个文件，以 128 个 ttf 字体文件为主，另附 1 个 sh 一键安装脚本，整体约 58.08MB，字体覆盖符号、西文与部分中文字形，脚本则用于批量写入系统字体目录，省去逐个手动添加的繁琐。目前已有 1434 人学习下载，说明该问题在 Ubuntu 与 WPS 组合中较为普遍。拿到资源后，读者可直接获得一套可复用的字体补充方案，既能恢复文档符号的正常显示，也能为后续同类环境部署提供参考，适合初涉 Linux 办公环境或需要长期稳定使用 WPS 的用户。

1. 为什么你的 WPS 在 Ubuntu 上总弹“字体缺失”

如果你在 Ubuntu 上装完 WPS Office，打开一份别人发来的.docx或.pptx，大概率会看到顶部飘出一条黄色提示：“系统缺失字体”。点开文档一看，宋体变成了某个歪歪扭扭的替代字形，行距错乱，PPT 里的艺术字直接糊成一团。这不是 WPS 的 bug，也不是 Ubuntu 的锅，而是 Linux 发行版出于版权合规，默认不带 Windows 那套商业中文字体。WPS Linux 版在渲染文档时会按字体名去系统里找对应 ttf，找不到就回退到默认字体，于是排版就“玄学”了。

这个资源包解决的就是这件事：把 WPS 在 Linux 下最常缺的那批中文字体（宋体、黑体、仿宋、楷体、微软雅黑等）整理成可直接安装的 ttf 集合，让你在 Ubuntu 上打开文档时不再弹窗、不再错位。适合两类人：一是刚切到 Linux 做日常办公、被字体问题反复折磨的普通用户；二是需要批量部署 WPS 到多台机器的运维或 IT 支持人员。下面我从字体到底缺在哪、怎么装、装完怎么验证、哪些坑会翻车，一步步拆开讲。

2. 先搞清楚 WPS 到底在找哪些字体：ttf 命名与 fontconfig 匹配逻辑

2.1 WPS 缺字体的本质是 fontconfig 找不到 family name

Linux 下字体管理靠 fontconfig，它维护一套字体缓存，应用程序通过 family name（字体族名）来请求字体。WPS 在渲染文档时，会读取文档里记录的字体名，比如“宋体”“SimSun”“Microsoft YaHei”，然后交给 fontconfig 去匹配。如果系统里没有任何一个字体的 family name 或 alias 能对上，fontconfig 就返回默认字体，WPS 检测到实际使用字体与请求字体不一致，就弹出缺失提示。

这里有个容易混淆的点：字体文件名和 family name 不是一回事。你从某处拷来一个simsun.ttf，文件名看着对，但用fc-scan一看，它的 family name 可能是SimSun也可能是宋体，甚至可能是SimSun-ExtB。WPS 请求的是哪个名字，取决于文档里嵌入的字体记录。所以光把 ttf 丢进字体目录还不够，得确认 family name 能被 fontconfig 正确识别。

常见做法是先用fc-list看看系统当前认了哪些中文字体，再对照 WPS 提示缺失的字体名，缺哪个补哪个。不要一上来就把网上能找到的所有中文字体全装进去，字体装太多会拖慢 fontconfig 缓存重建，还可能因为 family name 冲突导致匹配到错误的字形。

2.2 用 fc-list 和 fc-match 定位缺失项

在动手装字体之前，先做一次体检。打开终端，执行下面这组命令，看看系统里现在有什么、WPS 要的能不能匹配上。

# 列出系统已识别的所有中文字体（按 family name 去重） fc-list :lang=zh family | sort -u # 模拟 WPS 请求“宋体”，看 fontconfig 实际会返回哪个字体 fc-match "宋体" fc-match "SimSun" fc-match "Microsoft YaHei" # 查看某个 ttf 文件的 family name 和 style fc-scan --format "%{family} | %{style}\n" /path/to/your/font.ttf

fc-list :lang=zh family里的:lang=zh是过滤条件，只列支持中文的字体；sort -u去重，避免同一个 family 出现多行。fc-match是关键诊断命令，如果它返回的不是你期望的字体，而是DejaVuSans.ttf之类，说明匹配失败，WPS 就会报缺失。

fc-scan用来验证你手头 ttf 的真实 family name。有些资源包里的字体文件名写的是simsun.ttf，但 family name 可能是SimSun或宋体，甚至带版本后缀。把fc-scan的输出和 WPS 提示的缺失字体名对照，能避免装完还是弹窗的尴尬。

提示：fc-match支持同时传多个参数做批量检查，比如fc-match "宋体" "黑体" "楷体"，一次看完常用字体匹配情况。

2.3 字体目录该放哪里：用户级 vs 系统级

Ubuntu 下字体可以放在两个位置，选择取决于使用范围。

用户级目录不需要 sudo，装完只影响自己，适合先试水。系统级目录需要 root 权限，但一次安装所有用户都能用，运维批量部署时更省事。我一般先在用户级目录验证字体 family name 和 WPS 匹配效果，确认没问题再挪到系统级做正式部署。

无论放哪，装完都要执行fc-cache -fv重建缓存，否则 fontconfig 不会立刻感知新字体。-f强制刷新，-v输出详细过程，方便确认新字体有没有被扫到。

3. 把 ttf 装进系统并让 WPS 认出来：完整操作流程

3.1 准备字体文件与目录结构

拿到字体资源包后，先别急着全选复制。建议按字体族建子目录，方便后续排查和卸载。比如：

# 在用户级字体目录下按字体族建子目录 mkdir -p ~/.local/share/fonts/wps-fonts/{simsun,simhei,simkai,simfang,msyh} # 假设资源包解压在 ~/Downloads/wps-fonts-pack/ # 把对应 ttf 拷到各自目录（文件名以实际为准） cp ~/Downloads/wps-fonts-pack/simsun.ttc ~/.local/share/fonts/wps-fonts/simsun/ cp ~/Downloads/wps-fonts-pack/simhei.ttf ~/.local/share/fonts/wps-fonts/simhei/ cp ~/Downloads/wps-fonts-pack/simkai.ttf ~/.local/share/fonts/wps-fonts/simkai/ cp ~/Downloads/wps-fonts-pack/simfang.ttf ~/.local/share/fonts/wps-fonts/simfang/ cp ~/Downloads/wps-fonts-pack/msyh.ttc ~/.local/share/fonts/wps-fonts/msyh/

这里注意.ttc和.ttf的区别：.ttc是字体集合，一个文件里可能包含多个字体（比如宋体和新宋体打包在一起），fc-scan会列出多个 family。.ttf通常是单一字体。拷贝时保持原文件名，不要随意改名，因为 fontconfig 虽然主要看 family name，但文件名在某些匹配场景下也会参与。

如果资源包里字体文件很多，可以用循环批量拷贝，但建议先fc-scan扫一遍确认每个文件的 family name，避免把不相关的字体混进来。

3.2 重建 fontconfig 缓存并验证

拷贝完成后，执行缓存重建，然后用fc-list和fc-match双重验证。

# 重建用户级字体缓存，-f 强制，-v 显示详情 fc-cache -fv ~/.local/share/fonts/ # 确认新字体已被识别 fc-list | grep -iE "simsun|simhei|simkai|simfang|yahei" # 再次模拟 WPS 请求，确认匹配结果不再是 DejaVu fc-match "宋体" fc-match "SimSun" fc-match "Microsoft YaHei"

fc-cache -fv的输出里会列出扫描到的目录和新增字体数量。如果某个目录显示 0 个字体，说明文件格式不对或权限有问题。fc-list | grep用来确认 family name 是否按预期出现，注意 grep 不区分大小写，因为 family name 可能是SimSun也可能是simsun。

fc-match的返回结果如果从DejaVuSans.ttf变成了simsun.ttc: "SimSun"之类，说明匹配成功。这时候再打开 WPS，之前弹窗的文档应该不再提示缺失，排版也会恢复正常。

注意：如果fc-match "宋体"仍然返回 DejaVu，但fc-match "SimSun"正常，说明字体 family name 是英文的，而文档里记录的是中文名。这种情况需要在 fontconfig 配置里加 alias，把中文名映射到英文 family。

3.3 用 fontconfig 配置补 alias 解决中英文名不匹配

有些文档里字体名记录的是“宋体”，但 ttf 的 family name 只有SimSun，fontconfig 不会自动把中文名当别名。这时候需要写一个 fontconfig 配置文件做映射。在~/.config/fontconfig/conf.d/下新建99-wps-fonts.conf：

<?xml version="1.0"?> <!DOCTYPE fontconfig SYSTEM "fonts.dtd"> <fontconfig> <!-- 把中文常用字体名映射到实际 family name --> <alias binding="same"> <family>宋体</family> <accept><family>SimSun</family></accept> </alias> <alias binding="same"> <family>黑体</family> <accept><family>SimHei</family></accept> </alias> <alias binding="same"> <family>楷体</family> <accept><family>KaiTi</family></accept> </alias> <alias binding="same"> <family>仿宋</family> <accept><family>FangSong</family></accept> </alias> <alias binding="same"> <family>微软雅黑</family> <accept><family>Microsoft YaHei</family></accept> </alias> </fontconfig>

binding="same"表示这种映射是等价替换，fontconfig 在匹配时会优先考虑。<accept>里写实际的 family name，需要和fc-scan的输出一致。写完配置文件后再次执行fc-cache -fv，然后fc-match "宋体"应该就能返回 SimSun 了。

这个配置文件的好处是不用改字体文件本身，也不依赖 WPS 的字体替换设置。批量部署时把这个 conf 文件一起分发到各机器的~/.config/fontconfig/conf.d/或/etc/fonts/conf.d/，能省掉大量重复排查。

4. 避坑与排查：字体装了但 WPS 还是弹窗的几种情况

4.1 现象：fc-list 能看到字体，WPS 仍提示缺失

原因通常有三种。一是 WPS 进程在装字体之前已经启动，字体缓存没重新加载。解决方法是完全退出 WPS（包括后台进程wpscloudsvr等），再重新打开。可以用pkill -f wps确保所有相关进程结束。

二是字体文件权限不对，fontconfig 扫到了但当前用户读不了。检查ls -l确认 ttf 文件至少有r权限，目录有x权限。用户级目录一般不会出这个问题，但从别处拷贝时可能带上奇怪的权限。

三是 family name 和文档记录的名字对不上，且没有配 alias。用fc-scan看实际 family name，再对照 WPS 提示的缺失字体名，补 alias 配置。

4.2 现象：fc-match 返回了字体，但字形明显不对

这种情况多半是匹配到了同名的错误字体。比如系统里同时存在两个 family name 都叫SimSun的 ttf，一个来自资源包，一个来自某个第三方软件自带，fontconfig 按缓存顺序选了后者。用fc-list | grep -i simsun看有几个条目，如果有多个，把不需要的删掉或移出字体目录，再fc-cache -fv。

另一个可能是.ttc集合里包含了多个字体，fontconfig 匹配到了集合里的另一个 family。用fc-scan看 ttc 里到底有哪些 family，确认 WPS 请求的那个是否在列表里。

4.3 现象：装完字体后系统整体中文显示变细或变糊

这通常是因为新装的字体 family name 和系统默认中文字体冲突，fontconfig 把默认 sans-serif 或 serif 的匹配结果改掉了。比如某些资源包里的“微软雅黑”family name 被设成了sans-serif的优先项，导致整个桌面环境的中文都变成雅黑。

解决方法是检查/etc/fonts/conf.d/下有没有优先级过高的配置文件，或者在自定义 conf 里用<match target="pattern">限定只对特定 family 做 alias，不要动全局默认。我一般会在 conf 里加一条<match target="pattern"><test name="family"><string>sans-serif</string></test>...来确认默认匹配没被意外改写。

4.4 现象：批量部署到多台机器后部分机器仍报缺失

批量部署时最容易忽略的是每台机器的 fontconfig 缓存状态和已有字体差异。有的机器之前装过其他中文字体，family name 冲突；有的机器~/.config/fontconfig/下有旧配置覆盖了新 alias。

建议批量部署时统一走系统级目录/usr/share/fonts/truetype/wps-fonts/，配置文件放/etc/fonts/conf.d/，然后用脚本统一执行fc-cache -fv。部署后跑一遍fc-match检查清单，把常用字体名逐个验证，不要只看fc-list有没有。

4.5 现象：WPS 里手动设置字体替换后，换台机器又失效

WPS 的字体替换设置是保存在用户配置里的，换机器不会跟着走。如果依赖手动替换，每台新机器都要重设一遍。更稳的做法还是从 fontconfig 层面做 alias，让 WPS 在请求字体时就能匹配到，不依赖 WPS 内部设置。这样无论换哪台机器，只要字体和 conf 到位，打开文档就是正常的。

5. 进阶技巧：用脚本一键检查 WPS 字体健康度

装完字体不是终点，后续系统更新、WPS 升级、新文档引入新字体，都可能让缺失提示重新出现。我习惯写一个检查脚本，把常用字体名和 WPS 实际匹配结果列出来，一眼就能看出哪个没对上。

#!/usr/bin/env bash # wps-font-check.sh：检查 WPS 常用中文字体在 fontconfig 中的匹配情况 # 用法：bash wps-font-check.sh FONTS=("宋体" "SimSun" "黑体" "SimHei" "楷体" "KaiTi" "仿宋" "FangSong" "微软雅黑" "Microsoft YaHei") echo "=== WPS 字体匹配检查 ===" for f in "${FONTS[@]}"; do # fc-match 输出格式：文件名: family result=$(fc-match "$f" 2>/dev/null) # 判断是否匹配到了 DejaVu 等默认字体 if echo "$result" | grep -qiE "dejavu|liberation|noto.*sans"; then echo "[缺失] $f -> $result" else echo "[正常] $f -> $result" fi done echo "" echo "=== 当前中文字体列表（去重） ===" fc-list :lang=zh family | sort -u

脚本里FONTS数组列出 WPS 最常请求的字体名，中英文都放进去，因为不同文档记录的名字不一样。fc-match的结果如果包含dejavu、liberation或noto sans这类默认回退字体，就标记为缺失。最后再列一遍系统已识别中文字体，方便对照。

这个脚本我一般放在~/bin/下，加到 PATH 里，每次系统大更新或 WPS 升级后跑一遍。如果输出里出现[缺失]，就按第 3 章的流程补字体或补 alias。批量部署时也可以把这个脚本分发下去，让每台机器自检后上报结果，比人工一台台打开 WPS 试要快得多。

从那以后我每次在新机器上装完 WPS，都会先跑一遍这个检查脚本，确认所有常用字体都匹配正常再开始干活。希望帮到你。

本文还有配套的精品资源，点击获取