企业官网建设流程全解析

1. 别急着翻设置菜单，先搞清楚Unity的"中文"到底指什么

很多人一搜"Unity切换成中文"，脑子里想的是把编辑器界面变成中文。这个需求本身没问题，但实际操作之前得先分清三件事：编辑器界面语言、代码里的中文字符显示、打包后运行时显示的中文文本。这三件事的解决路径完全不同，混在一起搞，就会出现"我明明切成中文了，怎么游戏里还是方块"这种经典困惑。

我见过太多新手在这上面绕弯子。有人把编辑器语言改成中文之后，发现脚本里写的中文字符串在Game视图里变成了一堆问号或者豆腐块，然后回头去翻语言设置，翻来翻去也找不到问题所在。原因很简单——编辑器界面语言和字体渲染是两套独立的系统，前者是Unity自己维护的本地化资源，后者依赖你项目里导入的字体文件是否包含中文字形。

所以这篇内容我打算按"从编辑器到运行时"的顺序，把Unity中文化的完整链路拆开讲。适合刚接触Unity、想把开发环境调成中文的初学者，也适合已经能跑项目、但被中文显示问题卡住的开发者。核心关键词就一个：Unity中文，但围绕它展开的细节远比想象中多。

先说结论：Unity编辑器的中文界面在较新版本里是官方支持的，不需要装第三方汉化包；而游戏内的中文显示，永远取决于你用的字体资源，跟编辑器语言没有任何关系。记住这句话，后面所有的操作你都能对上号。

2. Unity编辑器界面切换中文的完整路径与版本差异

2.1 官方语言包的安装入口在哪里

Unity从2019版本之后逐步完善了多语言支持，到2021及以后的LTS版本，中文（简体）已经是官方内置的可选语言之一。操作路径是：打开Unity Hub，进入Installs标签页，找到你已安装的编辑器版本，点击右侧的齿轮图标或者三个点菜单，选择Add modules。在弹出的模块列表里往下滚，会看到一个Language packs分组，里面列出了简体中文、繁体中文、日语、韩语等选项。勾选简体中文，确认后等待下载安装完成。

这里有个容易忽略的点：语言包是作为模块单独下载的，不是随编辑器主程序一起装的。如果你当初安装编辑器时没勾选语言包，现在补装完全来得及，不需要重装整个编辑器。下载体积不大，通常几十兆，网速正常的话一两分钟就搞定。

安装完成后，重启Unity编辑器。注意是重启编辑器本身，不是重启Hub。重启之后进入Edit > Preferences（Windows）或者Unity > Preferences（macOS），在左侧列表里找到Languages这一项。如果语言包装好了，这里会出现Editor Language的下拉菜单，选择Chinese (Simplified)，然后点击界面上的提示重启编辑器使设置生效。

2.2 为什么你装了语言包却看不到中文选项

这是问得最多的一个问题。语言包装了，Preferences里却找不到Languages菜单，或者下拉菜单里没有中文。常见原因有三个：

第一，编辑器版本太老。2019之前的版本基本没有官方多语言支持，那个年代大家用的是第三方汉化补丁，把汉化文件覆盖到编辑器安装目录的Data文件夹里。这种做法现在不推荐了，一是版本兼容性差，二是覆盖官方文件容易导致编辑器异常。如果你还在用很老的版本，最省事的办法是升级到2021 LTS或更新的版本。

第二，语言包没有真正安装成功。有时候Hub显示已安装，但实际上文件没写完整。可以去编辑器的安装目录下检查，路径大概是Editor\Data\Localization，里面应该有对应语言的文件夹。如果没有，回Hub里把语言包取消勾选再重新勾选一次。

第三，Preferences里的Languages项被隐藏了。这种情况比较少见，通常和编辑器配置文件损坏有关。可以尝试删除编辑器配置目录下的偏好设置文件让它重新生成，但操作前记得备份。Windows下路径在%APPDATA%\Unity\Editor-5.x这类位置，macOS在~/Library/Preferences/Unity/下面。

提示：切换编辑器语言不会影响你项目的任何资源、脚本或构建设置。它只是改变了编辑器UI的显示文字，项目文件本身没有任何改动，可以放心切换。

2.3 中文界面下那些"翻译了但没完全翻译"的地方

切成中文之后你会发现，Unity的本地化并不彻底。菜单栏、Inspector面板的字段名、Preferences里的大部分选项都变成了中文，但有几个地方仍然是英文：

• Console窗口里的报错信息：这些是编译器和运行时的输出，基本保持英文，因为报错信息涉及大量技术术语，翻译反而容易造成歧义。
• Package Manager里的包描述：大部分包的名称和描述还是英文，只有少数官方包做了本地化。
• 部分第三方插件的界面：插件作者如果没有提供中文资源，界面就还是英文。
• Shader和材质相关的属性名：这些通常保持英文原样。

这不是bug，是正常的本地化覆盖范围问题。我的建议是，即使你用中文界面，也要慢慢熟悉这些英文术语，因为你在搜索解决方案、看官方文档、逛技术社区的时候，遇到的几乎全是英文关键词。中文界面降低的是上手门槛，但英文术语的积累不能停。

3. 编辑器中文了，游戏里的中文为什么还是方块

3.1 字体资源才是中文显示的唯一决定因素

这是整个中文化过程中最关键、也最容易被误解的一环。Unity的Text组件（无论是老的UI Text还是TextMeshPro）在渲染文字时，会去你指定的字体资源里查找每个字符对应的字形。如果字体文件里没有中文字形，那这个字就渲染不出来，显示成方块、问号或者干脆空白。

Unity默认使用的字体是Arial（在部分版本里是Liberation Sans），这个字体不包含中文字形。所以你在Text组件里输入"你好世界"，Game视图里看到的很可能是一排方块。这跟编辑器是不是中文界面毫无关系，哪怕你把编辑器切成中文，默认字体该不认中文还是不认。

解决办法就是导入一个包含中文字形的字体文件。常用的选择有：

导入方式很简单：把.ttf或.otf文件直接拖进Project窗口的Assets目录下，Unity会自动生成字体资源。然后在Text组件的Font字段里把这个字体拖进去，中文就能正常显示了。

3.2 TextMeshPro的中文字体图集生成流程

如果你用的是TextMeshPro（现在新建项目默认就是TMP），流程会多一步——需要生成字体图集（Font Asset）。TMP不会直接使用ttf文件，而是要把字体里用到的字符烘焙成一张纹理图集，运行时从图集里取字形。

具体操作：Window > TextMeshPro > Font Asset Creator。在Source Font File里选择你导入的中文字体，然后关键是Character Set的选择。如果选ASCII，那只有英文字符；要显示中文，得选Custom Characters或者Unicode Range。

用Custom Characters的话，你把项目里会用到的所有中文字符粘贴进去，TMP只烘焙这些字，图集小、性能好。缺点是后期加字要重新生成。用Unicode Range的话，可以填4E00-9FFF覆盖CJK基本区，但这样图集会非常大，一张4096x4096的图集可能都不够用，而且很多字你根本用不到，浪费显存。

我的实际做法是：先用Custom Characters把常用字烘焙进去，比如游戏UI里固定的那些文字。如果游戏有大量动态中文文本（比如玩家昵称、聊天内容），那就得用Unicode Range，并且把图集尺寸调大，Atlas Resolution选4096x4096，Padding设小一点比如2或3，尽量塞进更多字形。生成之后检查一下图集利用率，如果超过90%就得考虑拆成多个字体资源。

注意：TMP的字体图集是静态的，运行时不能动态添加新字形。如果你的游戏需要显示任意中文（比如用户输入），要么预烘焙足够大的字符集，要么换用支持动态字体的方案。

3.3 动态字体与静态图集的取舍

老版本的UI Text组件支持动态字体模式，字体资源会在运行时根据需要动态生成字形并缓存。这个模式对中文很友好，因为不需要预先知道会用到哪些字。但动态字体有几个问题：首次显示某个字时会有生成开销，可能造成卡顿；字体纹理缓存会随着使用不断增长，内存占用不可控；在移动设备上表现尤其明显。

TMP走的是静态图集路线，性能稳定可控，但灵活性差。现在Unity主推TMP，新项目基本都用它。折中方案是：UI固定文本用TMP静态图集，需要动态显示大量中文的场景单独处理，比如用一个专门的动态字体资源，或者把可能的字符范围预先烘焙好。

4. 脚本文件里的中文注释和字符串，坑比你想的多

4.1 文件编码不对，中文全是乱码

Unity的C#脚本文件默认使用UTF-8编码。如果你用某些编辑器（尤其是Windows上一些老旧的文本编辑器）保存脚本时用了GBK或者ANSI编码，那脚本里的中文注释和字符串在Unity里打开就会变成乱码。

判断方法很简单：在Unity里双击打开脚本，如果中文显示正常，那编码没问题；如果是一堆看不懂的符号，那就是编码不对。解决办法是用VS Code、Rider或者Visual Studio把文件另存为UTF-8格式。VS Code右下角会显示当前文件编码，点击可以切换并保存。

这里有个细节：UTF-8 with BOM和UTF-8 without BOM。Unity对这两种都能识别，但有些工具链对BOM敏感。我的习惯是统一用UTF-8 without BOM，避免在某些构建环节出问题。VS Code默认保存就是无BOM的UTF-8，用起来比较省心。

4.2 字符串里的中文在Inspector里显示正常但运行时出问题

有时候你在脚本里写了一个中文字符串，Inspector里看没问题，但运行起来显示异常。这种情况通常和字符串的序列化有关。Unity在序列化字符串时用的是UTF-8，如果字符串来源是外部文件（比如JSON、CSV），那外部文件的编码就很重要。

举个例子：你从Excel导出一个CSV配置文件，里面有一列中文文本。Excel默认导出的CSV在中文Windows上是GBK编码。你用File.ReadAllText读进来，如果不指定编码，.NET会按系统默认编码解析，在中文系统上可能碰巧对，但换到英文系统或者打包到其他平台就乱码了。正确做法是读取时显式指定UTF-8：

string content = File.ReadAllText(path, System.Text.Encoding.UTF8);

或者更稳妥的方式，用StreamReader并指定编码检测：

using (var reader = new StreamReader(path, System.Text.Encoding.UTF8, true)) { string content = reader.ReadToEnd(); }

4.3 不同平台下的中文路径问题

这个问题在打包到移动端或者某些主机平台时特别容易冒出来。如果你的资源加载路径里包含中文，比如Resources.Load("中文目录/配置文件")，在编辑器里可能跑得好好的，打包到Android上就找不到资源了。

原因是不同平台对文件路径的编码处理不一致。Android的AssetBundle系统对非ASCII路径的支持有限，iOS相对好一些但也不建议用中文路径。最稳妥的做法是：所有资源路径、文件名、目录名一律用英文和数字，中文只出现在最终显示给用户的文本内容里。这条规则看起来简单，但实际项目里因为美术同学导出文件时用了中文命名而踩坑的情况太常见了。

如果已经有一堆中文命名的资源，可以在导入时用AssetPostprocessor批量重命名，或者写个编辑器脚本统一处理。但最好的办法还是从项目一开始就定好命名规范，从源头避免。

5. 打包发布后的中文显示，平台差异得提前摸清

5.1 Android平台的中文字体回退机制

Android系统本身自带中文字体，但Unity打包后的应用默认不会去调用系统字体，除非你显式配置。如果你在Unity里没有指定中文字体，打包到Android上，Text组件可能显示空白或者方块，而不是像在编辑器里那样至少有个默认字体兜底。

解决办法还是老一套：在项目里导入中文字体并正确引用。但Android上有个额外注意点——字体文件会增大包体。一个完整的中文字体动辄十几兆，如果直接打包进去，APK体积会明显增加。优化手段是字体子集化：只保留项目实际用到的字符，把字体文件裁剪到最小。可以用FontSubsetPack之类的工具，或者自己写脚本根据项目里的文本资源提取字符集。

另外，Android 8.0之后系统对字体有更细的管理，某些定制ROM可能会影响字体加载。测试阶段建议在多种机型上验证，不要只在一台开发机上跑通了就认为没问题。

5.2 WebGL平台的中文渲染特殊性

WebGL平台的中文显示有它自己的脾气。因为WebGL运行在浏览器里，字体渲染走的是浏览器的文本渲染管线，和原生平台不一样。如果你用的是TMP，字体图集是打包在资源里的，显示效果各平台一致。但如果用的是老的UI Text加动态字体，WebGL下的表现可能和编辑器差异较大。

还有一个常见问题：WebGL打包后中文字体文件太大导致加载慢。浏览器需要先下载字体资源才能渲染文字，如果字体文件十几兆，用户会看到一段时间的空白。解决办法同样是子集化，或者用系统字体方案——在WebGL里可以通过CSS或者JavaScript调用浏览器所在系统的字体，但这需要和网页端配合，纯Unity层面做不了。

5.3 微信小游戏等小游戏平台的中文适配

小游戏平台对包体大小极其敏感，通常首包限制在几兆到十几兆。一个完整中文字体直接就把预算吃光了。这类平台上的通用做法是：

• 使用平台提供的系统字体接口，不打包字体文件，运行时调用系统字体渲染。
• 对必须打包的字体做极致子集化，只保留UI固定文案用到的字。
• 动态文本走服务端渲染或者图片替换，避免在客户端处理大量中文字形。

Unity转小游戏平台时，这些细节需要提前和平台适配方案对齐，不能照搬原生平台的思路。

6. 那些年我在Unity中文化上踩过的真实坑

6.1 语言包装了但菜单还是英文的排查过程

有一次帮朋友处理一个问题：他在Unity Hub里装了中文语言包，Preferences里也选了Chinese，但菜单栏还是英文。重启了好几次都没用。

排查步骤是这样的：先确认语言包文件是否真的在安装目录下，去Editor\Data\Localization看有没有zh-hans文件夹，结果发现文件夹存在但里面是空的。说明Hub下载了但解压失败。解决办法是在Hub里先取消勾选语言包，等它卸载完，再重新勾选安装。这次装完之后文件夹里有了完整的资源文件，重启编辑器就正常显示中文了。

这个坑的教训是：Hub显示"已安装"不代表文件完整，遇到语言不生效的情况，先去安装目录确认文件是否真的存在。

6.2 TMP字体图集生成失败的那些原因

用Font Asset Creator生成中文字体图集时，最常见的失败原因是图集分辨率不够。选了Unicode Range4E00-9FFF，图集尺寸还是默认的1024x1024，生成到一半就报错说图集满了。中文字符数量太多，小图集根本装不下。

解决办法：把Atlas Resolution调到4096x4096，Padding降到2，同时把Character Set改成Custom Characters，只填项目实际需要的字。如果还是不够，就分多个字体资源，比如常用字一个、生僻字一个，TMP支持字体回退列表（Fallback Font Assets），可以配置多个字体按顺序查找。

另一个失败原因是字体文件本身的问题。有些字体文件带了版权保护或者子集化限制，Font Asset Creator读不出来。换一个开源字体通常就能解决。

6.3 中文输入框在移动端的兼容性问题

如果你的游戏有玩家输入昵称的功能，用Unity的InputField或者TMP_InputField，在移动端弹出系统键盘输入中文时，可能会遇到候选词栏遮挡输入框、输入法切换后文字不更新等问题。

这类问题的根源在于Unity的输入框和原生输入法之间的交互。不同平台、不同输入法的表现差异很大。比较稳妥的做法是：在移动端使用平台原生的输入框覆盖在Unity视图上方，输入完成后再把文本传回Unity。Unity官方和一些第三方插件都提供了这类方案，虽然接入麻烦一点，但兼容性比直接用Unity的InputField好得多。

如果项目对输入体验要求不高，也可以限制输入字符集，只允许英文和数字，避开中文输入法的兼容性问题。这算是一种产品层面的取舍。

7. 一套可复用的Unity中文化检查清单

把上面这些内容整理成一套操作清单，下次新开项目或者接手别人项目时，可以按这个顺序过一遍：

编辑器层面：

1. 确认Unity版本在2021 LTS或更新
2. 通过Hub安装简体中文语言包
3. 在Preferences > Languages里切换编辑器语言
4. 重启编辑器验证菜单是否变为中文

项目字体层面：

1. 导入包含中文字形的字体文件（推荐思源黑体或阿里巴巴普惠体）
2. 如果用TMP，通过Font Asset Creator生成中文字体图集
3. 根据项目文本量决定用Custom Characters还是Unicode Range
4. 配置TMP的Fallback Font Assets作为补充

脚本与资源层面：

1. 确保所有C#脚本保存为UTF-8 without BOM
2. 外部配置文件（JSON/CSV）统一用UTF-8编码
3. 资源路径和文件名避免使用中文
4. 读取外部文本时显式指定UTF-8编码

打包发布层面：

1. 对中文字体做子集化，控制包体大小
2. 在目标平台上实测中文显示效果
3. 小游戏平台优先考虑系统字体方案
4. 移动端输入框考虑原生输入方案

这套清单不能覆盖所有情况，但能帮你避开大部分常见的坑。Unity的中文化本身不复杂，复杂的是各个环节之间的关联和平台差异。把这条链路理清楚了，后面遇到问题就知道该往哪个方向查。

最后分享一个我自己的习惯：在项目初期就建一个专门的中文字体测试场景，里面放几个Text和TMP组件，分别显示常用字、生僻字、标点符号和数字混排。每次换字体或者改TMP设置之后，先跑这个场景看一眼，确认没问题再继续开发。这个场景花不了十分钟搭建，但能省下后面大量排查显示问题的时间。