Unity TextMeshPro中文本地化：动态最小字体集解决乱码与模糊

做过中文本地化的Unity同学，多半都经历过TextMeshPro带来的“字体地狱”：英文好好的，一切中文就变方框；好不容易在Font Asset Creator里把常用字烘焙进去，换上之后边缘又开始发虚；真机上内存还跟着爆。这个“Unity TextMeshPro 中文本地化：动态生成最小字体集”方案，就是奔着这两个老大难去的。它不引入额外插件，核心思路是：在编辑器阶段收集项目里真实出现的中文文本，动态生成一个只包含这些字符的最小字体集，运行时再按需加载并走字体回退链。这样做既能避开动态字体集运行时疯狂补字导致的卡顿和模糊，又能把图集体积和内存控制在可接受范围。适合正在做中文本地化、或者已经遇到方框乱码/字体发虚，想找一个可落地方案的开发同学参考。

1. 为什么中文本地化总是绕不开乱码和模糊

1.1 乱码的本质：不是TextMeshPro坏了，是字体集里压根没有这个字

很多人第一次遇到中文乱码时，第一反应是去查Unity版本、查编码格式，甚至怀疑是不是TextMeshPro组件坏了。这个排查方向在大部分场景下是错的。TextMeshPro本身不负责“翻译”字符，它只负责“把字符映射到字体图集里的字形”。中文字符能不能显示出来，取决于你当前使用的Font Asset里有没有这个字符对应的glyph（字形）。如果字体集里没有，TextMeshPro就会渲染一个表示“缺失字形”的方框，或者直接放空。

所以说白了，乱码不是“乱”，而是“缺”。缺的原因主要有三种：

• 字体集是静态烘焙的，烘焙时收录的字符范围不够，比如只烤了ASCII和少量标点。
• 字体集是动态的，但运行时报错后没有正确回退到中文字体，文本就全部变成豆腐块。
• 文本来源是配置表或服务器下发，里面包含的字符超出了你烘焙时预判的范围。

我在做项目时踩过最深的坑，是本地化文本分散在Excel、ScriptableObject和Prefab三个地方，用Font Asset Creator手工选了“Chinese Simplified + 常用3000字”，结果上线前美术改了句对白，里面有个生僻字“堃”，整个界面瞬间出现一个刺眼的方框。所以“常用字表”这种静态思路本身就不可靠，真正的可靠方案是：让字体集跟着项目里的文本走，项目里有什么字，字体集就装什么字。

1.2 边缘模糊的根源：动态字体集的“重建”与“采样点”问题

如果说乱码是“缺字”，那边缘模糊就是“采样”出了问题。TextMeshPro为了应对任意文本，提供了Dynamic模式的字体集：运行时遇到字体集里没有的字，就会实时把新字形加入图集。听起来很方便，但在中文本地化场景下它有一个致命问题：中文常用字就有三千多个，一旦文本量大，动态图集很快就会膨胀到上限，然后触发重新分配和重建。

这个重建过程不是无感的。图集重新排布后，原本已经生成的glyph位置会变，画面里已经渲染好的文字需要重新采样；如果此时动态字体集的采样点设置不当，或者图集在重建过程中被截断，就会出现“边缘发虚”“笔画发糊”的现象。更麻烦的是，动态补字是逐字触发的，在大段中文一次性显示时，一帧里要补几十上百个字，卡顿几乎不可回避，而且每次补字都可能触发图集重排，模糊问题就反复出现。

还有一种情况容易被忽略：动态字体集的Sampling Point Size设置过小。比如默认用36，你做的是1080p以上分辨率的UI，文字被放大到中号标题时，字形位图本身分辨率不够，采样放大后边缘自然发虚。这个不是“坏了”，是“精度不够”。要根治模糊，不能靠事后调模糊参数，要靠图集生成时就把字形采样精度定到位。

2. 最小字体集方案的整体设计与选型逻辑

2.1 先算一笔账：一个图集到底能装下多少中文字

既然要做“最小字体集”，先得知道我们的预算空间是多少。TextMeshPro的字体图集是正方形纹理，常用尺寸有1024、2048、4096。字形大小由Sampling Point Size决定，值越大，单个字形占的像素越多，清晰度越高，图集能容纳的字数越少。

粗略估算公式是：图集总像素数 ÷ 单字形像素数。以4096×4096图集、采样点72为例，每个字形连同留白大约占100×100像素，那么一个图集大约能装下1600个字符。若把采样点降到36，单字形约50×50，一个图集能装下约6400个字符。中文常用字是3500个左右，这意味着“全量中文+常用标点”在72采样点下已经逼近图集上限，稍不留神就会溢出并触发多图集支持。

所以方案设计的第一步就是：不要妄图把所有中文都塞进去，而是只塞“项目里实际出现”的中文。绝大多数游戏的文案总量，包括UI、剧情、配置表、运营活动，去重后一般也就是2000到5000个字符。如果我们把这些字符精确定位，配合72采样点生成，一个4096图集就能覆盖绝大多数情况；万一超过，再启用MultiAtlas支持，把溢出字符放到第二个图集，运行时通过fallback链正常渲染。

2.2 三种字体集方案的对比，以及我为什么选“动态收集+静态烘焙”

TextMeshPro的中文字体集方案，实际项目中大致有三条路可以走。

第一种是纯静态烘焙。把所有中文字符（GB2312或Unicode基本区）全部烘焙进图集，简单粗暴。缺点是图集会非常大，同时字体的动态扩展能力为零，遇到表外字符还是乱码。而且全量字符的Font Asset在真机上加载很慢，AssetBundle打包也大，属实用不起。

第二种是运行时纯动态。不烘焙任何中文字符，遇到什么补什么。初看很美好，但结合上一节的“重建”问题，它在中文场景下体验很差。补字卡顿、图集重排导致模糊，甚至个别机型上动态建图集还会因为驱动差异出现渲染花屏。我最早用这个方案，被测试机上的中文界面折腾到怀疑人生。

第三种就是本文章要讲的“动态收集+静态烘焙”。核心思路是：在打包前，用一个编辑器脚本扫描项目中所有会显示文本的地方，把中文字符收集起来，去重后作为字符源，烘焙出一个静态Font Asset。这个Asset内容虽然固定，但字符来源是动态的、随项目内容变化的。运行时不需要再补字，也就没有动态图集重建和补字卡顿的问题；同时字符列表来自真实文本，不会像“常用字表”那样漏字。

三条路一对比，结论很清楚：静态烘焙稳，但不能全量；动态补字灵活，但中文场景下问题太多。只有“动态收集+静态烘焙”这个组合，同时拿到了灵活和稳定。

2.3 方案架构与数据流：从文本到字体Asset的完整链路

整个方案的数据流可以拆成四段：

• 文本收集器：在编辑器下扫描所有Prefab、ScriptableObject、本地化配置表（CSV/Excel导出）、以及代码里硬编码的中文字符串，提取所有中文字符。
• 字符处理器：去重、排序、过滤掉空白字符和完全不需要的符号，生成一个有序字符列表，同时输出一份“缺字报告”。
• 字体生成器：用TMP的Font Asset Creator API或底层FontEngine，把这个字符列表烘焙进一张4096×4096的图集，生成Font Asset。
• 运行时加载器：把生成好的Font Asset接入资源管理，设置好字体回退链，让动态字体优先回退到这个最小字体集。

这套架构最关键的优点是“闭环”。文本变更不需要美术或程序手工去重建字体，只要重新跑一次编辑器脚本，字体集就会跟着变。这也是我推荐给团队时，大家接受度最高的原因：不需要改美术工作流，只需要在构建流程里加一步。

3. 实操全流程：从文本收集到运行时加载

3.1 第一步：在编辑器下收集所有需要显示的中文文本

收集文本是整套方案的地基，也是细节最多的一步。很多人以为“我只要把Localization目录下的CSV读一遍就行”，但实际项目里，文本来源远不止配置表。我的收集器会覆盖四个来源：

• 场景中所有TMP_Text组件的text属性。
• Resources、Addressables、AssetBundle目录下所有Prefab里TMP_Text的文字。
• ScriptableObject中的本地化字段，以及自定义的对话、物品名、技能描述。
• 代码里直接赋给TMP_Text.text的字符串字面量（这个没法全自动扫，需要做白名单或者让策划统一走配置表）。

收集动作的核心代码，用一个EditorWindow包裹起来比较合适，手动点击“Scan and Build”就能跑完。核心逻辑大致是这样：

csharp复制var allGuids = AssetDatabase.FindAssets("t:Prefab t:ScriptableObject", new[] { "Assets/GameData", "Assets/UI", "Assets/Localization" });
var chars = new HashSet<char>();

foreach (var guid in allGuids)
{
    var path = AssetDatabase.GUIDToAssetPath(guid);
    var objs = AssetDatabase.LoadAllAssetsAtPath(path);
    foreach (var obj in objs)
    {
        if (obj is TMP_Text tmpText)
        {
            CollectFromString(tmpText.text, chars);
        }
        // 这里继续处理 ScriptableObject 中的字符串字段，可用反射遍历
    }
}

// 另外读取导出的本地化配置
var lines = File.ReadAllLines("Localization/zh-CN.csv");
foreach (var line in lines)
{
    CollectFromString(line, chars);
}

CollectFromString里只保留中文字符，同时把常用标点也纳入，但会过滤掉换行、制表符、以及多余空格。这块有一个经验：中英文混排时，英文和数字交给默认的拉丁字体集就行，不需要混进中文字体集。这样能省下大量图集空间，也避免中文图集里出现奇怪的拉丁字形采样。

收集完成后，我会生成一份缺字报告，列出“哪些文本包含的字符不在基础6000字范围内”，发到策划群让他们确认。这一步在做中文本地化时特别重要，因为生僻字通常意味着某个文案可能需要替换表达，而不是一味往字体集里加字。

3.2 第二步：生成最小字体集Asset

拿到字符列表后，下一步就是烘焙字体集。这一步我推荐直接在Editor脚本里调用TextMeshPro的FontAssetCreator底层接口，按固定的采样参数生成，而不是让策划或美术去手动点窗口。

我们项目里采用的参数是：Source Font用思源黑体或苹方（视授权情况），采样点72，Padding 8，RenderMode用SDFAA，图集4096×4096，开启MultiAtlas支持。72像素的采样点是牺牲一部分图集容量换清晰度的选择，实际测试下来，在1080p和2K分辨率下表现都不错。如果团队做的是低端机适配，或者UI里几乎不会出现大号文字，可以降回48，能多塞很多字符。

生成代码的核心片段如下，我用的是TMP_FontAsset.CreateFontAsset的重载：

csharp复制var font = Resources.Load<Font>("Fonts/SourceHanSansSC-Regular");

var tmpFontAsset = TMP_FontAsset.CreateFontAsset(
    font,
    72,
    8,
    GlyphRenderMode.SDFAA,
    4096,
    4096,
    AtlasPopulationMode.Static,
    true
);

// 如果字符集较大，后续可以分批遍历字符，用 FontEngine 查询并添加 glyph
// 这一步实际会调用到 TMP 内部的 glyph 装载逻辑
tmpFontAsset.name = "MinimalCNFont_" + charCount + "chars";
AssetDatabase.CreateAsset(tmpFontAsset, "Assets/GameData/Fonts/" + tmpFontAsset.name + ".asset");

这里有个容易踩的坑：不同TMP版本里CreateFontAsset的签名有差异，Unity 2021和Unity 2022的TMP包版本不同，参数可能需要微调。我的习惯是封装一层兼容适配，按当前TMP版本做条件编译或反射调用。另外，如果用动态收集的字符列表去驱动glyph装载，建议分段调用，避免一次性加载几千个字导致Editor卡死。

烘焙完成后，在Project窗口里双击这个Font Asset检查一下：看图集分布是否均匀、有没有字形重叠、边缘是否有大块黑边。黑边严重的话，把Atlas Padding从8调到12，或者调整RenderMode为SDFAA_HINTED，大部分都能解决。

3.3 第三步：运行时加载与字体回退链配置

字体Asset生成出来后，剩下就是运行时怎么把它用起来。我推荐的做法不是直接替换所有TMP_Text的font，而是配置TextMeshPro的字体回退链：默认字体仍用项目原有的拉丁字体，拉丁字体无法渲染的字符，自动回退到我们的中文最小字体集。

实现方式有两种：

第一种是在全局设置里配置。打开TMP Settings，把生成的中文字体集添加到Fallback Font Assets列表里。这样所有使用默认字体的TMP_Text，在遇到中文字符时都会自动回退。这是最省事的方式，改动量最小。

第二种是代码式按需注入。如果你用的是Addressables或自定义资源加载框架，可以在启动时异步加载中文字体集，然后手动把fallback挂到默认字体上：

csharp复制var defaultFont = TMP_Settings.defaultFontAsset;
var cnFont = await ResLoader.LoadAsync<TMP_FontAsset>("MinimalCNFont");
if (defaultFont != null && cnFont != null)
{
    defaultFont.fallbackFontAssetTable.Add(cnFont);
}

注意，fallbackFontAssetTable的操作最好在游戏启动期完成，不要在运行时频繁增删，否则可能导致字体解析缓存不一致。另外，这个操作是全局性的，一旦挂上，所有TMP_Text都会感知到，所以字体集加载完成后，需要用Profiler盯几帧，确认没有出现“字体解析风暴”。

3.4 第四步：常见效果验证与Profiler检查

方案上了之后，别急着打包，先在编辑器里做一轮专项验证。我的验证清单包括：

• 全文本扫描一遍，确认没有任何界面出现方框字符。
• 在Character视图里输入测试文本，覆盖所有配置表里出现的中文标点。
• 用Frame Debugger切到实际文字绘制那一帧，确认文字使用的是中文字体集里的字形，而不是默认字体的missing glyph。
• 打开Profiler，加载字体集后看内存占用，重点是Texture2D和FontAsset两个类别。

如果出现个别字仍是方框，先不要怀疑字体集，回到第一步重新跑收集器，大概率是某个配置表路径没被扫描到。这个闭环有个好处：跑一次就自愈了，不用每次手动改字体集。

4. 常见问题与排查技巧实录

4.1 方框/豆腐块的排查路径

遇到方框，按这个顺序排查：

• 确认字体集Asset里有没有这个字符。用TMP Asset Inspector打开Character Table搜索即可。
• 确认这个字符是不是零宽字符或不可见控制字符。U+200B、U+FEFF这类字符在图集里看不到，但会挡在文本中间，别被迷惑。
• 确认文本来源是不是真的被收集器扫到了。最常见的情况是运营后台配置的动态文案，没经过CSV导出，压根没进收集列表。
• 确认fallback链没断。如果你的默认字体没有正确配置fallback，中文就回退不到中文字体集。

对比经验：纯中文界面出现方框，90%是收集遗漏；中英混排出现方框，多半是fallback链断裂。

4.2 文字边缘发虚发糊的排查路径

模糊问题的排查，主要集中在两个地方。

先看Sampling Point Size。如果你用36采样点做最小字体集，在PC上4K分辨率下全屏文字放大后边缘一定发虚。这不怪TMP，是字形位图本身精度不够。把采样点提到72重新生成，模糊基本能消失。

再看图集是否发生重建。打开TMP Settings里的Dynamic Font System状态，如果图集重建次数很多，说明你已经被迫在跑动态补字模式。这个模式下出现模糊是常态，因为重建后字形采样位置会变化。解决办法就是回到第三步，确保运行时走的是静态最小字体集，而不是动态模式。

如果两个地方都确认过还模糊，检查一下Atlas Padding和RenderMode。有个项目是RenderMode用了SDFAA_HINTED，在部分安卓机型上会出现边缘锯齿，后来改成SDFAA就正常了。

4.3 缺失字符的运行时兜底

即便收集器做得再全，也防不住运营后台临时发一个更新文本，里面带了个全新生僻字。如果不想等下次打包，可以在运行时加一层兜底：监听TMP的missing glyph事件，把缺的字符动态添加到一个“小型动态补充字体集”里，当作fallback链的最末尾。

这个补充字体集不用大，512×512就够了，只负责处理临时新增的字符。它平时是空闲的，只有真正碰到缺字才会补。因为次数极少，触发重建的概率和性能影响都可忽略。我实际用下来，一个版本周期内通常也就触发一两次。

代码上可以这样实现一个简单的兜底：

csharp复制var fallbackDynamic = TMP_FontAsset.CreateFontAsset(
    sourceFont,
    72,
    8,
    GlyphRenderMode.SDFAA,
    512,
    512,
    AtlasPopulationMode.Dynamic,
    false
);

把这个动态小字体集加到默认字体的fallback链末尾。注意它不是主力，只是最后一道防线，所以即便它有动态补字的小毛病，也不会影响整体体验。

4.4 实操中容易忽略的几个细节

说几个容易踩但我比较少看到有人分享的细节。

• 字体文件授权问题。中文字体不是随便打包就行的，思源黑体是SIL开源协议，苹方不行，商用项目要提前确认授权。这个不搞清楚，以后要返工。
• 不要在构建机上重新随机生成字体集。字符集顺序、图集排布最好固定，否则每次构建的AssetHash都会变，增量打包体验会很差。建议把生成的字符列表和字体集都提交进版本库。
• TMP的Dynamic字体系统默认会缓存“已解析字符”，如果运行时改了很多文本，这个缓存会占内存。项目里如果频繁切换多语言，建议定期清理TMP_FontAsset的glyph缓存。
• 字体集的加载建议做成异步。一个4096图集+几千个glyph，加载耗时不是0，放到启动Loading阶段做，不要放在切场景时做。

5. 扩展方向与个人体会

5.1 多语言版本的扩展思路

这个方案本质是“按需准备字形”，所以并不仅限于中文。做日文、韩文、泰文、阿拉伯文时，逻辑完全一样，只要替换掉字符筛选规则即可。韩文要做元音辅音组合，泰文要做上下标规则检查，阿拉伯文要处理连字变形，功能上TMP本身支持，关键是字符收集器里要把Unicode区块筛对。

我的做法是在编辑器脚本里做一个“语言配置项”，每种语言对应一组Unicode范围：

csharp复制var ranges = new Dictionary<string, (int start, int end)[]>
{
    ["zh-Hans"] = new[] { (0x4E00, 0x9FFF), (0x3000, 0x303F) },
    ["ja"] = new[] { (0x3040, 0x30FF), (0x31F0, 0x31FF) },
    ["ko"] = new[] { (0xAC00, 0xD7AF) },
    // 其他语言自行补充
};

选择要发布的语言后，收集器按对应范围过滤并生成独立的字体集。这样一套资源管理逻辑可以管所有语言，策划只需要在配置表里填对应语言的文本。

5.2 一些可以继续优化的方向

我目前在项目上还有两个方向在尝试，不一定对，但可以参考。

一个是字体集热更。把最小字体集挂到热更资源目录，运营后台发新文本时，如果收集器跑出来有缺字，只下发一个补充字体集Asset，而不是重新打整个包。这个和4.3的运行时兜底可以配合使用。

另一个是UI文字字体分级。把UI里的大标题、正文、小提示分开用不同采样点的字体集，大标题用96采样点，正文用72，小提示用48。从采样成本上更精细，但会带来更多FontAsset管理成本，适合对画质要求很高的项目。

回看这套方案，我个人最深的体会是：中文本地化的字体问题，绝对不能靠“多烤几千个常用字”来糊弄，也不能靠“运行时让TMP自己补”来躺平。真正稳定落地的方式，就是让字体集和项目内容保持同步，让每一个渲染出来的中文字符都有据可查。把文本收集、字体生成、运行时加载这条链路做成自动化的闭环之后，乱码和模糊就不再是每日纠缠你的问题了。后续如果有新语言、新文本，整个团队的操作成本都会低很多。