PICO Neo3风格化村庄优化：URP下Alpha Clip与LOD实战
2026/10/1 13:21:34
装完 Kali 之后第一次登录，十有八九会遇到同一个画面：桌面菜单全是英文，终端里敲个ls中文文件名的目录直接变问号，浏览器里想打中文发现根本没输入法。很多人以为去设置里把语言改成中文就完事了，结果重启一看，登录界面还是英文，终端还是乱码，输入法装了就像没装一样。这个标题说的“设置中文语言环境”，真正要解决的是从系统底层 locale、到图形桌面、再到输入法和终端显示的一整条链路，而不是某一个勾选项。
我自己在物理机、双系统、虚拟机、持久化 U 盘上前后折腾过好几轮 Kali 的中文环境，踩的坑基本集中在“改了不生效”“重启就还原”“输入法候选框不出现”这三类。这篇就把这几层拆开讲清楚，从 locale 机制是什么、为什么要分别设置、每一步为什么这么写，到出问题怎么一步步排查，给你一套能直接照着复现的完整方案。不管你是刚装完系统的新手，还是想把之前半吊子中文环境彻底理顺的老用户，都能从中找到对得上的操作。
1. 装完 Kali 满屏英文，中文环境到底包含哪几层
很多人对“中文环境”的理解停留在“界面语言换成中文”，但实际用起来会发现，界面切成中文之后，终端里的中文文件名照样显示成方块或者问号。原因就在于，界面语言、编码 locale、字体、输入法这四件事是相互独立又彼此依赖的，任何一层缺失，最终看到的效果都不完整。
先建立这个整体认知，后面每一步才知道自己在干什么。
1.1 界面语言、locale、字体、输入法四层分工
我们把这四层拆开看，每一层负责的东西完全不同：
- 界面语言（translation）：桌面环境、软件菜单里显示的“文件”“编辑”这些文字，靠的是系统里的翻译文件。它决定你看到的菜单是不是中文。
- locale 区域设置：决定系统怎么处理字符编码、日期格式、货币、排序规则。它不直接翻译界面，但决定终端、脚本、文件名里的中文能不能正常显示和比较，是整条链路的地基。
- 字体：就算 locale 和翻译都对了，如果没有装中文字体，系统找不到对应字形，中文就会显示成方块（俗称“豆腐块”）。
- 输入法：负责让你把中文“打进去”。它和前面三层相对独立，前三个都配好了，你依然可能一个字都打不出来。
关键点在于，这四层里locale 是地基。如果 locale 不是 UTF-8，后面字体和输入法搞得再对，终端和文件系统层面的中文还是可能出问题。所以我一直建议：先配 locale，再谈界面和输入法，顺序别乱。
1.2 为什么 Kali 默认锁死在 en_US.UTF-8
Kali 是基于 Debian 的，默认语言环境是en_US.UTF-8。这个默认值不是随便定的，它背后有几个现实考虑：一是英文环境在报错信息、日志、命令行工具的输出上更统一，出问题时搜索关键字命中率更高；二是很多安全工具的文档和参数说明都是英文语境，保持英文能减少术语翻译带来的歧义；三是默认英文能避免一部分软件在非英文 locale 下的兼容性问题。
所以你会发现，Kali 官方其实不太鼓励你把系统语言整体切成中文，尤其是做命令行操作的时候。英文报错能直接拿去搜，中文报错反而不好查。这也是我自己的做法：locale 层面坚决用 UTF-8 保证中文能正确显示，但系统主语言可以保留英文，只在桌面层面按需切中文。这样既解决了乱码，又不丢掉英文报错的可读性。
理解了这个取舍，你就不会纠结“到底该不该全切中文”这个问题了——答案是根据你的使用场景来定，而不是一刀切。
1.3 UTF-8 和 GBK 混用是乱码的根源
中文乱码十次有八次是因为编码不一致。UTF-8 是目前 Linux 世界的事实标准，而 GBK、GB2312、GB18030 是历史遗留的中文编码。如果你在 Windows 那边存了一个 GBK 编码的中文文本，直接拷到 Kali 里用 UTF-8 打开，就会出现经典乱码。
所以做中文环境时，所有环节的编码都要统一到UTF-8：locale 用zh_CN.UTF-8或者en_US.UTF-8（都是 UTF-8 编码，只是区域不同），终端编码设成 UTF-8，编辑器保存文件时选 UTF-8 无 BOM。只要编码链路上任何一环掉到 GBK，中文显示就会出问题。这一点在做中文环境时是底线，值得专门记住。
搞清楚了这四层分工和编码统一的底线，接下来就可以动手了。第一步，永远是从 locale 开始。
2. 生成并挂载中文 locale，让终端先能认出中文
locale 是整条链路的地基，先把它做扎实。这一步的核心动作就两个：生成zh_CN.UTF-8这个 locale，然后把它挂载成系统识别到的区域设置。听起来简单，但“生成”和“挂载”是两个独立步骤，很多人只做了其中一个，导致改了不生效。
下面从查看现状开始，一步步来。
2.1 先看清当前 locale 到底是什么状态
动手之前先摸清现状，这是排错的习惯。打开终端，敲：
locale你会看到类似这样的输出：
LANG=en_US.UTF-8 LANGUAGE= LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" ... LC_ALL=再敲一个命令看系统里已经生成了哪些 locale：
locale -a如果输出里没有zh_CN.utf8（注意大小写，命令输出通常是.utf8不带横线），说明中文 locale 还没生成。这时候直接去改LANG变量是没用的，因为系统里根本没有这个 locale 的数据，改了会报 “Cannot set LC_ALL to default locale” 之类的警告，或者干脆回退到默认值。
提示：
locale和locale -a是排查 locale 问题最常用的两条命令，建议养成先看现状再动手的习惯，能省掉大量猜测。
看清现状之后，下一步才是生成 locale。
2.2 生成 zh_CN.UTF-8 的两种路径对比
生成中文 locale 有两种常见方式，效果一样，但适用场景不同。
方式一：交互式配置（推荐新手）
sudo dpkg-reconfigure locales执行后会弹出一个选择界面，先用方向键翻到zh_CN.UTF-8 UTF-8，按空格键打上星号选中，回车确认。接着会让你选择“系统默认 locale”，这一步如果你想保持英文界面，可以选en_US.UTF-8；如果你就想让系统尽量中文，可以选zh_CN.UTF-8。选完后它会自动生成。
方式二：手动编辑配置文件（推荐熟练用户/脚本化）
直接编辑/etc/locale.gen：
sudo nano /etc/locale.gen找到这一行，把前面的#去掉：
zh_CN.UTF-8 UTF-8保存退出后执行：
sudo locale-gen看到 “Generating locales... zh_CN.UTF-8... done” 就说明生成成功了。
两种方式本质一样，方式一只是帮你自动修改了/etc/locale.gen并调用locale-gen。如果你想脚本化批量部署（比如一次性配置好几台机器），方式二更可控。
| 对比项 | dpkg-reconfigure locales | 手动编辑 locale.gen |
|---|---|---|
| 操作难度 | 低，交互式 | 中，需知道改哪行 |
| 可控性 | 一般 | 高，可脚本化 |
| 适合场景 | 单机新手 | 批量/自动化/服务器 |
| 是否自动生成 | 是 | 需手动跑 locale-gen |
生成完成后，再敲一次locale -a | grep zh_CN验证，看到zh_CN.utf8就成了。
2.3 系统级默认 locale 该往哪儿写
locale 生成之后，要让它成为默认值，得写进配置文件。这里有个关键点：不同配置文件的作用范围和优先级不一样，写错地方会导致“改了不生效”。
最稳妥的系统级写法是编辑/etc/default/locale：
sudo nano /etc/default/locale写入：
LANG=zh_CN.UTF-8 LANGUAGE=zh_CN:en_US注意这里是zh_CN.UTF-8，带横线，写配置时就用这个格式。LANGUAGE是给程序翻译用的，zh_CN:en_US表示优先中文，没有中文翻译时回退英文，这个写法在桌面软件里很有用。
除了/etc/default/locale，还有几个位置也会影响 locale，按优先级从高到低大致是：/etc/environment、~/.profile、~/.bashrc。千万别在多个文件里同时设冲突的值，否则你会陷入“改了 A 被 B 覆盖”的循环。我的建议是：系统级统一写/etc/default/locale，个人级微调写~/.profile，~/.bashrc只放需要交互式 shell 生效的东西。
2.4 LC_ALL、LANG、LANGUAGE 三个变量的优先级
这三个变量是 locale 里最容易搞混的地方，搞懂了能省掉一半的排错时间。
- LANG：主语言设置，其他没单独指定的
LC_*都跟着它走，是最基础的默认值。 - LC_ALL：最高优先级，一旦设置，会覆盖所有
LC_*和LANG。所以除非特殊需求，平时不要设 LC_ALL，设了它，你在别处改LANG就没用了。 - LANGUAGE：这个变量只影响“消息翻译”（也就是界面文字），不影响编码、日期格式这些。它支持多语言回退列表，比如
zh_CN:en_US。
它们的关系可以这么理解：LC_ALL> 具体LC_*>LANG。LANGUAGE是另一条独立的线，只管翻译。
注意：如果你改完 locale 后
locale命令报错，先检查是不是LC_ALL或某个LC_*被设成了系统里不存在的 locale。这种情况在从别处拷贝配置文件的场景下特别常见。
到这里，locale 地基就打好了。终端应该能正常识别中文了。但图形桌面和登录界面还可能是英文，接下来处理这一层。
3. 图形桌面与登录界面切成中文的实操
locale 配好之后，你会发现一个奇怪的现象：终端里中文正常了，但桌面菜单、右键菜单还是英文。这是因为图形界面语言是另一套机制，主要靠LANGUAGE环境变量和桌面环境自己的语言设置。这一章就以 Kali 默认的 XFCE 桌面为例，把界面和登录界面一起理顺。
3.1 XFCE 语言设置与 lightdm 登录界面的差异
XFCE 的语言设置在“设置管理器”里能找到“语言支持”或者“Language Support”之类的入口，进去把语言改成中文（简体）应用即可。但要注意，这个改动只影响登录之后的桌面会话，登录界面（lightdm）的显示是独立的。
登录界面之所以还是英文，是因为 lightdm 在用户登录之前就启动了，那时候用户级的语言设置还没加载。要改 lightdm 的语言，得在系统层面配置。编辑：
sudo nano /etc/default/locale确认里面的LANG和LANGUAGE是中文相关设置。如果想让登录界面也显示中文，通常还需要在 lightdm 配置里指定 locale，或者确认系统的LANG已经是中文。改完重启或重新登录生效。
这里给个我自己的取舍建议：登录界面保持英文其实完全无所谓，它上面就那么几个字，而且英文反而更干净。所以除非有强迫症需求，这一步可以略过，把精力放在更影响使用的输入法和终端上。
3.2 只显示一半中文？字体缺失才是主因
不少人界面切了中文后，发现菜单里一部分字正常、一部分显示成方块，或者干脆整片豆腐块。这几乎可以确定是中文字体缺失。
解决方法是安装中文字体包。Kali 基于 Debian，字体源是现成的：
sudo apt update sudo apt install fonts-noto-cjk fonts-wqy-microhei fonts-wqy-zenhei这三个包分别提供不同的中文字体，装完基本能覆盖绝大多数中文显示场景：
| 字体包 | 说明 | 适用场景 |
|---|---|---|
| fonts-noto-cjk | 覆盖面广，字形现代 | 桌面界面、浏览网页 |
| fonts-wqy-microhei | 文泉驿微米黑，体积小 | 终端、轻量场景 |
| fonts-wqy-zenhei | 文泉驿正黑，字形清晰 | 桌面界面、文档阅读 |
装完之后，如果部分程序还是方块，可以执行一次字体缓存刷新：
fc-cache -fv提示：判断是不是字体问题的快捷方法——如果英文正常、只有中文变方块，那基本是字体缺失；如果中文变成问号或者乱码符号，那更可能是编码（locale）问题。两者症状不同，处理方向也不同。
3.3 时区、键盘、日期格式的连带调整
中文环境配好了，还有几个连带的设置建议一起处理，不然会有“语言是中文但时间不对”“日期格式看着别扭”这类小别扭。
时区：
sudo dpkg-reconfigure tzdata按提示选亚洲、上海即可。或者用命令直接设：
sudo timedatectl set-timezone Asia/Shanghai键盘布局确认：
sudo dpkg-reconfigure keyboard-configuration一般选 Generic 105-key PC，布局选 English (US) 就行，中文输入是靠输入法解决，不是靠键盘布局。日期格式跟着 locale 走，你上面把 locale 设成中文，日期通常就会显示成中文格式。
到这一步，桌面和登录界面应该都顺眼了。接下来是最容易卡住的一环：输入法。
4. 中文输入法落地，从安装到能真正打出字
界面中文、字体中文都搞定了，但你会发现一个字都打不出来——因为输入法是独立的一套东西。这一章专门讲输入法，从选型、安装到环境变量配置，再到候选框不出现的排查，一步不落。
4.1 为什么现在推荐 fcitx5 而不是老 fcitx 或 ibus
Linux 下的中文输入法框架主要有三个：ibus、fcitx（老版本）、fcitx5。我的建议很明确：新装系统直接上 fcitx5。
原因是：ibus 在一些桌面环境上和输入法框架的兼容性偶有摩擦，配置起来也偏繁琐；老 fcitx 已经停止主要维护，新一代工具链适配跟不上；fcitx5 是当前活跃维护的版本，对 GTK、Qt 的支持完善，配置界面也更友好，中文输入体验明显更顺。
选型对比大概是这样：
| 框架 | 维护状态 | 兼容性 | 推荐度 |
|---|---|---|---|
| fcitx5 | 活跃 | 好，GTK/Qt 支持完善 | 强烈推荐 |
| fcitx（老） | 基本停滞 | 一般 | 不建议新装 |
| ibus | 活跃 | 部分桌面上略繁琐 | 可用但非首选 |
选好框架，安装就简单了。
4.2 安装 fcitx5 与中文输入法引擎
一条命令把核心组件装齐：
sudo apt install fcitx5 fcitx5-chinese-addons fcitx5-frontend-gtk3 fcitx5-frontend-gtk2 fcitx5-frontend-qt5逐个说明为什么要装这些：
fcitx5：输入法框架本体。fcitx5-chinese-addons：中文附加组件，里面有拼音、双拼、五笔等输入引擎，这个是打中文的关键。fcitx5-frontend-gtk3、gtk2：让 GTK 程序（如 XFCE 里大量程序）能用 fcitx5 输入。fcitx5-frontend-qt5：让 Qt 程序（如一些工具软件）也能输入。
很多人只装了前两个，结果在浏览器或者某些程序里打不出中文，就是漏了 frontend 包。输入法框架和程序之间的“桥”就是这些 frontend 包，缺了它们，框架再好也连不上程序。
装完之后，配置输入法：
fcitx5-configtool在界面里把“拼音”添加到当前输入法列表，用快捷键（默认Ctrl+Space）就能切换了。
4.3 环境变量配置与开机自启
光装好还不够，得告诉系统和各个程序“输入法用的是 fcitx5”。这靠一组环境变量：
GTK_IM_MODULE=fcitx QT_IM_MODULE=fcitx XMODIFIERS=@im=fcitx在 XFCE 下，推荐写进~/.xprofile，因为这个文件在图形会话启动时被读取：
nano ~/.xprofile写入：
export GTK_IM_MODULE=fcitx export QT_IM_MODULE=fcitx export XMODIFIERS=@im=fcitx保存后重新登录生效。
至于开机自启，fcitx5 通常装完会自动配置一个自启项，如果没有，在“设置管理器 - 会话和启动 - 应用程序自启”里手动加一条fcitx5命令即可。
注意：如果你是用 SSH 连过去的、或者只是修改了
~/.bashrc，环境变量对图形程序是无效的——图形程序读的是~/.xprofile或/etc/environment。这是很多人“配了环境变量却没用”的根本原因。
4.4 切换不出候选框的完整排查链路
输入法最常见的故障就是：快捷键按了没反应，或者候选框不出现，跟没装一样。遇到这种情况别急着重装，按下面这个顺序排查，基本能定位到问题：
第一步，确认 fcitx5 进程在跑：
ps aux | grep fcitx5没有输出说明没启动，手动在终端敲fcitx5 &看能不能起来，报错信息会告诉你缺什么。
第二步，确认环境变量在图形会话里真的生效了。打开一个终端模拟器，敲：
echo $GTK_IM_MODULE如果输出为空或者不是fcitx，说明~/.xprofile没被读取，或者被别的配置覆盖了。
第三步，检查是不是没装对应的 frontend 包。比如你在某个具体程序里打不出字，其他程序正常，那多半是这个程序对应的 frontend 包缺失。
第四步，检查输入法列表里到底有没有加拼音引擎。fcitx5-configtool里如果输入法列表是空的，那按快捷键自然切换不出任何东西。
第五步，确认快捷键没冲突。有些桌面环境或程序会占用Ctrl+Space，换个快捷键试试。
这个排查顺序是从“进程有没有活”到“桥有没有搭”再到“配置对不对”，逐层缩小范围，比盲目重装高效得多。我自己遇到候选框不出现，八成是环境变量没在图形会话里生效，改~/.xprofile重登就好。
输入法通了，接下来处理最后一个高频痛点：终端和远程连接里的中文乱码。
5. 终端、SSH 和脚本里的中文乱码定位与修复
桌面中文、输入法都通了，但很多人会在终端里再次撞上乱码墙：本地终端中文正常，一 SSH 连过去就乱；或者本地终端里中文文件名显示成问号。这一章专门定位这几类问题。
5.1 本地终端乱码的三种典型来源
本地终端的乱码，来源主要有三种，症状各有特征：
第一种，locale 不是 UTF-8。症状是中文显示成问号或者一堆字符。回到locale命令确认一下LANG和LC_CTYPE是不是 UTF-8 结尾。
第二种，字体缺失。症状是中文显示成方块。这个装字体就能解决，参照前面第三章。
第三种，终端模拟器自己的编码设置不是 UTF-8。这个比较隐蔽，终端模拟器（如 XFCE Terminal）有自己的编码选项，如果被设成了其他编码，即使系统 locale 是对的，终端显示也会错。检查终端设置里的编码选项，确保是 UTF-8。
判断逻辑很简单：问号/乱码偏向编码问题，方块偏向字体问题。按这个分就能快速定位。
5.2 SSH 远程连 Kali 中文字符的显示问题
SSH 场景下的中文问题分两个方向：从别的机器 SSH 连到 Kali，或者从 Kali SSH 连到别的机器。
关键在于，SSH 默认不会把本地的 locale 环境变量完整传到对端。所以你可能本地终端是 UTF-8，连过去却乱码。解决办法是在 SSH 客户端配置里显式发送 locale 相关变量，编辑~/.ssh/config或/etc/ssh/ssh_config，加入：
SendEnv LANG LC_*同时确保对端的 sshd 配置允许接收这些变量（AcceptEnv指令）。两边都配好，locale 才能通过 SSH 传递。
如果嫌麻烦，还有个更直接的办法：连过去之后在远端 shell 里手动确认locale是 UTF-8，如果不是，在远端改好/etc/default/locale即可。远端的 locale 是根本，客户端传不传其实只是补充。
5.3 脚本与文件名里用中文的注意事项
最后聊一个容易被忽略的点：脚本和文件名里的中文。
在 UTF-8 环境下，用中文文件名和中文变量名理论上都没问题，但实际使用中建议能不用中文就不用，尤其是脚本变量名和路径。原因是：跨系统传输（比如从 Windows 拷文件过来）时，中文文件名很容易因为编码不一致出问题；脚本里如果用中文变量名，在不同 locale 环境下执行结果可能不一致。
如果确实需要处理中文文件名，至少保证整个流程的编码统一到 UTF-8，编辑器保存文件时选 UTF-8 无 BOM。我自己的习惯是：目录名和文件名尽量用英文或拼音，中文只出现在实际内容里，这样能避开 90% 的诡异问题。
终端和远程这块理顺了，最后我们来处理那些“配了又失效”的顽固问题，以及不同安装形态下的差异。
6. 配置重启后失效与特殊安装形态的差异处理
前面所有步骤都做对了，还可能遇到一种让人抓狂的情况：配好了，重启一变回原样。这一章专门讲失效排查和几种特殊安装形态下的注意点。
6.1 重启后 locale 又变回英文的排查表
“改了不生效”或“重启还原”是有规律可查的，按下面的表格逐项核对，基本能定位：
| 症状 | 可能原因 | 处理方向 |
|---|---|---|
| 重启后 LANG 变回 en_US | locale 没写进系统级配置文件 | 检查 /etc/default/locale |
| 终端改了，桌面没变 | 图形会话没读到系统设置 | 检查 ~/.xprofile 和桌面语言设置 |
| 部分程序中文，部分英文 | LANGUAGE 回退设置不完整 | 设 LANGUAGE=zh_CN:en_US |
| 改了 A 文件又被 B 覆盖 | 多个配置文件设了冲突值 | 统一到系统级单点配置 |
| 输入法环境变量失效 | 写进了 ~/.bashrc 而非 ~/.xprofile | 移到图形会话配置文件 |
核心原则就一条：系统级配置单点化，不要在多处设冲突值。把 locale 统一放/etc/default/locale，图形会话的环境变量放~/.xprofile，个人微调放~/.profile，各司其职，就不会互相覆盖。
6.2 双系统、虚拟机、持久化 U 盘下的 locale 差异
不同安装形态下，locale 表现会有差异，这里说几个典型场景。
双系统（Windows + Kali）：两套系统对时间、编码的处理默认不同。Windows 常把硬件时间当本地时间，Kali 当 UTC，可能导致时间差。编码上，从 Windows 分区拷过来的 GBK 文件在 Kali 里会乱码，记得用iconv转码：
iconv -f GBK -t UTF-8 旧文件.txt -o 新文件.txt虚拟机（如 Hyper-V、VMware）：locale 配置方式和物理机一样，但要注意虚拟机的增强功能/工具包有时会影响键盘和显示，输入法在增强模式下偶尔有兼容问题。配置时优先保证 locale 和字体，输入法问题单独排查。
持久化 U 盘：这是最容易翻车的形态。所谓持久化，是把改动保存到 U 盘的一个分区里。如果你在非持久化模式下改了 locale，重启后全部丢失，所以务必确认你当前处于持久化模式再动手配置。另外，持久化分区的容量和读写策略也会影响配置的持久性，配置前先确认 U 盘有可用的持久化空间。
6.3 遇到疑难问题时的通用缩小范围方法
最后分享一个我处理疑难 locale 问题的通用思路：分层隔离，逐层验证。
先在最底层验证：开一个纯文本终端（不依赖图形），敲locale看编码对不对，echo 中文测试看能不能正常显示。底层通了，再进图形桌面验证菜单和字体。底层不通，就别在桌面层折腾，回到 locale 配置重来。
这样一层一层往上验证，比在图形界面里东改西改高效得多。具体操作上，可以用LANG=zh_CN.UTF-8 locale这种临时指定环境变量的方式，测试某个设置在不重启的情况下是否生效，快速验证配置值写对没有。
提示：临时验证用
LANG=zh_CN.UTF-8 命令这种前置变量的写法，不会改动系统配置，测完就恢复，是排查 locale 时非常实用的小技巧。
我自己在物理机和持久化 U 盘上反复折腾下来的体会是，中文环境这事的难点从来不在“怎么设”，而在“为什么设了没用”和“重启为什么没了”。把 locale、界面、字体、输入法这四层的关系理清楚，把系统级配置文件单点化，把图形会话变量放对位置，绝大多数问题都会自己浮出水面。真正省时间的做法不是到处搜“一键命令”，而是每次改完都用locale、locale -a、echo $GTK_IM_MODULE这几条命令验证一下当前状态，让每一步都有反馈。我现在的习惯是：装完系统先花十分钟把 locale 和字体配好，输入法放最后装，这样等真正开始用系统的时候，就不会被中文问题反复打断节奏了。如果后续还要在双系统或者虚拟机之间来回切，建议把中文环境的配置步骤记成一个自己的清单，重装或者换环境时照着走一遍，比临时回忆靠谱得多。