最近在 Kali Linux上装了 Android Studio，配上了 Claude Code 插件——这个插件能识别我在编辑器里选中的行、选中的文件，直接把它们作为上下文喂给 Claude。

于是在 AS 内置终端里愉快地用 Claude 写代码。然后撞上一件诡异的事：

在 AS 的任何地方都打不出中文。

不仅是和 Claude 对话的输入框，连代码里的中文注释、字符串字面量，全都只能敲出英文字符。诡异的是：按 Shift 切换输入法，fcitx5 状态栏会正常切到中文模式，输入法的候选词框也能正常弹出，敲拼音能看到候选词列表，整个输入法 UI 表现得和在 Firefox 里一模一样。但是——当你选中某个候选词、准备让它上屏的时候，字符既不会以中文形式落入编辑器，也不会以英文形式落入编辑器，而是直接消失，编辑器里什么都不会出现。

但奇怪的是：同一个 fcitx5，在 Firefox、Mousepad、Terminal 里全都好好的。只有 AS 中有问题。

更让人崩溃的是，我前后折腾了 fcitx4 → fcitx5 迁移、改快捷键、加 JVM 参数、替换 JBR，每一招看起来都"应该是对的"，每一招都没用。最后发现真正的元凶，是 Debian 安装器悄悄塞进 /root/.profile 的一行 LANG=C。

这篇文章就把整个排查过程（含弯路）原原本本记下来，给同样掉坑的同学一个参考。

先列清楚症状和边界条件，这是后续所有推断的基础：

边界很清楚：fcitx5 这边一切正常，连候选词框、候选词列表都看得到，但 AS 这边在选词上屏的瞬间字符被丢弃了。这是一个非常关键的信号——它说明输入法框架本身没问题，问题在「fcitx5 把 commit string 投递给 AS 之后」的那一段路径上。按键事件 fcitx5 拦到了，也正常处理了，唯独最后一步「把中文字符串交给 AS」失败了。结合 AS 是个 Java 应用、AWT 在 X11 下走 sun.awt.X11InputMethod（XIM 协议）这条相对"老派"的路径，排查方向应该收敛到 Java/输入法协议层，而不是继续在 fcitx5 配置上打转。

我一开始用的是 fcitx4（4.2.9.9）。想到 JBR 21 已经正式弃用对 fcitx4 的支持，社区里也有大量"JBR 21 + fcitx4 中文失效"的反馈，于是第一反应就是迁移到 fcitx5。

注意：Kali/Debian 新版已经移除了 fcitx5-googlepinyin 独立包，pinyin 表并入 fcitx5-chinese-addons（字典还是 Google 的）。第一次装会报 package not found，按这个调整即可。

写 ~/.xinputrc：

~/.xprofile 保留原有：

（fcitx5 对 fcitx 这个旧名字提供兼容，不用改成 fcitx5）

把 /usr/share/applications/org.fcitx.Fcitx5.desktop 复制到 /etc/xdg/autostart/，确保开机自启。

迁移本身完全成功，但 AS 还是打不出中文。 其他程序一切正常。

这条弯路的教训：社区里"换个输入法框架就好了"的建议，往往是因为提问者本来就只剩输入法框架的问题。但症状相同不等于根因相同。

迁移完测了一下，发现 fcitx5 默认的 Ctrl+Space 和 AS 的代码补全快捷键完全冲突。按下去先弹补全建议，输入法根本没机会响应。

改 ~/.config/fcitx5/config：

单按左/右 Shift 切换中英文，干净利落。

fcitx5-remote -r 让配置立即生效。

其他程序里 Shift 切换工作完美，AS 里依然哑的。 至少排除了快捷键冲突这个干扰因素，但问题本身没动。

这是 JetBrains 官方推荐的 JBR X11 输入法相关参数。文档说它强制 Java 重建 X11 输入法上下文，能解决一些 IME 不响应的问题。

编辑 /data/apps/android-studio/bin/studio64.vmoptions，加一行：

重启 AS。

用 jps -v 看 JVM 实际加载的参数（AS 的原生启动器 bin/studio 是个 ELF 二进制，不是 shell 脚本，没法直接 grep 命令行）：

参数确实加载了。

还是不行。 参数加载了但行为没变，说明问题不在这个开关上。

到这一步，开始怀疑是 JBR 21.0.8 本身有 bug。JetBrains Issue Tracker 上确实有 JBR-8496：某些场景下 CJK 输入法失效。issue 标记为已在更新版本修复。

于是去 JetBrains Runtime releases 找最新的 21 系列 build，选中 jbr_jcef-21.0.10-linux-x64-b1163.110.tar.gz（带 JCEF，AS 必需，比 21.0.8 新）。

操作（注意 Linux 下可以热替换，JVM 文件已经 mmap 进内存）：

退出 AS，从菜单重启。

仍然不行。 JBR 升级到 21.0.10，中文还是输不进去。

到这一步，所有的"常规嫌疑"都被排除了：输入法框架 ✅、快捷键 ✅、JVM 参数 ✅、JBR 版本 ✅。问题必然在更底层。

排查走到死胡同，回头重新审视「为什么 AS 收不到非 ASCII 字符」。

fcitx5 的 XIM 前端是通过 XIM 协议（X11 Input Method）和客户端通信的。Java AWT 在 X11 下用的就是 sun.awt.X11InputMethod，走 XIM 这条路。而其他 GTK/Qt 程序是通过 GTK_IM_MODULE/QT_IM_MODULE 直接加载 fcitx5 的原生 module，不走 XIM。

用 fcitx5-diagnose 看一眼：

AS 确实是通过 XIM 连上的，fcitx5 这边没有任何问题。

那么 XIM 链路是通的，但 Java 这一侧没在收 commit string —— 这种行为在 Java 社区里有个非常经典的解释：sun.awt.X11InputMethod 在初始化 input context 时会检查当前 locale，locale 不支持 CJK 时，它会退化成只接受 ASCII 的 passthrough，所有非拉丁字符的 commit string 直接丢弃。这恰好和我们看到的症状丝丝入扣：输入法 UI 正常显示（那是 fcitx5 自己画的）、拼音预输入和候选词列表正常工作（那是 fcitx5 自己的状态机），唯独最后一步「fcitx5 通过 XIM XmbCommitString 把中文字符串提交给 AS」时，Java 这边的 X11InputMethod 因为 locale 是 C，认定"我不需要处理 CJK"，把这些字符直接扔了。

那 AS 的 locale 是什么？直接看进程 environ：

LANG=C。

Java 在 LANG=C 下启动的 AWT，X11InputMethod 会判定"当前 locale 不需要 CJK 输入支持"，于是即使 XIM 协议层 fcitx5 已经生成好中文字符串准备 commit，Java 这一侧在收到 XmbCommitString 事件时直接把它们扔了。这就是为什么 AS 表现为「输入法 UI 全程正常、选词上屏时字符凭空消失」——一个非常迷惑人的中间态：看起来输入法在工作（确实在工作），但屏幕上什么也出不来。

奇怪了，我终端里明明是 en_US.UTF-8。怎么 AS 拿到的是 LANG=C？

查一下系统 locale 配置：

系统默认是对的。问题出在 XFCE 会话进程本身：

XFCE 会话本身就是 LANG=C，所有从菜单启动的图形程序都继承这个。

继续往上找。/root/.profile 第 8-12 行：

罪魁祸首找到。

Debian/Kali 安装器在用 root 装系统时，会主动写入这段配置。注释说得很清楚：因为 Linux 字符控制台（tty1~6）使用的 console font 不一定支持 zh_CN.UTF-8，会显示乱码，所以保险起见给 root 一个 LANG=C。

这个出发点是对的，但它有个致命的副作用：

那为什么我终端里是 en_US.UTF-8？因为 .bashrc 第 164-165 行又把它改回来了：

.bashrc 只对交互式 bash 生效。图形程序不读 .bashrc。于是 .profile 设错了，.bashrc 又悄悄把它修回来，两股力量在终端里抵消，问题被完美隐藏。只有从菜单启动的 X 应用才暴露真相。

思路很简单：.profile 里给一个既能在字符控制台显示、又能让 X 应用加载 CJK 输入法的 locale。

最完美的人选是 en_US.UTF-8：

改 /root/.profile：

LANGUAGE=C 保留——它只影响消息语言，不影响 locale 的字符编码判定，而且符合"root 用英文消息"的原意。

为了让修改不依赖重新登录就能立刻验证，同时改 /usr/share/applications/android-studio.desktop：

完全退出 AS，从菜单重启。

成了。 按 Shift 切到中文，「你好」两个字清清楚楚地出现在编辑器里。代码注释、Claude 对话框、字符串字面量，所有地方中文都能正常输入。

[招生]科锐逆向工程师培训(2026年7月3日实地，远程教学同时开班, 第56期)！