问题现象
在 Arch Linux、KDE Plasma Wayland 和 Fcitx5 环境中，出现了一个很奇怪的输入法问题：
- Brave 等部分原生 Wayland 应用中可以输入文字；
- 但中文、英文、日语之间的输入状态无法正常切换，或者状态显示与实际输入不一致；
- 关闭并重新打开浏览器，问题依旧可能存在；
- 系统重启后问题稳定复现。
更奇怪的是，某次调整 Waydroid 独立窗口模式并启动 Android 应用时，整个桌面环境发生崩溃。Plasma 和 KWin 恢复后，原本无法正常切换输入状态的应用突然全部恢复正常。
随后正常关闭并重新打开 Brave，输入法仍然正常。但整机重启后，问题又重新出现。
这个现象提供了一个很重要的线索：
问题不是浏览器进程本身的临时状态，而更可能发生在 KDE Plasma Wayland 会话启动阶段。
最初的判断
由于桌面崩溃后输入法恢复，而浏览器重启后仍然保持正常，可以初步排除：
- Brave 自身缓存损坏；
- 单一应用的输入法配置异常；
- 中文或日语输入引擎损坏；
- Waydroid直接修复了输入法。
更合理的解释是：
- Waydroid 触发了 KWin 或整个 Plasma 图形会话重建；
- Fcitx5、KWin 和应用之间的 Wayland 输入法连接被重新初始化；
- 原先错误的启动顺序或连接状态被清空；
- 新建立的输入法链路暂时恢复正常。
但这仍然只是推测，需要日志和配置证据进一步验证。
只读排查
为了避免继续扰动系统，首先进行了严格的只读审计，没有修改配置、没有重启进程，也没有重新运行 Waydroid。
重点检查了以下内容：
- 当前存在多少个 Fcitx5 主进程；
- Fcitx5 的父进程与启动来源；
- KWin 是否配置了 Fcitx5 Wayland Input Method；
- 是否还存在传统 XDG Autostart；
- systemd 用户服务中是否有额外启动路径；
- Brave 使用的是 Wayland 还是 XWayland；
- 当前启动和上一次桌面崩溃前后的日志时间线；
- D-Bus 中
org.fcitx.Fcitx5名称的持有情况。
最终发现，系统中同时存在两条 Fcitx5 启动路径。
第一条启动路径：KWin Wayland Input Method
KDE Plasma Wayland 中，Fcitx5 被配置为 KWin 的输入法组件，KWin 使用类似下面的 desktop 文件启动它：
/usr/share/applications/fcitx5-wayland-launcher.desktop
实际启动命令为：
fcitx5-wayland-launcher --reopen
这种方式是 KDE Plasma Wayland 下较合适的启动方式，因为 KWin 需要把 Fcitx5 作为 Wayland 输入法客户端管理，并建立原生 Wayland 输入协议连接。
第二条启动路径：传统 XDG Autostart
与此同时，系统软件包还提供了传统自启动文件：
/etc/xdg/autostart/org.fcitx.Fcitx5.desktop
这个文件会在桌面登录时再次尝试启动普通 Fcitx5 实例。
于是冷启动时出现了类似下面的顺序：
- KWin 先通过 Wayland launcher 启动 Fcitx5；
- 第一个 Fcitx5 成功取得 D-Bus 名称：
org.fcitx.Fcitx5
- Plasma 的传统 XDG Autostart 随后又尝试启动第二个 Fcitx5；
- 第二个实例发现 D-Bus 名称已经被占用；
- 第二个实例报错退出：
Unable to request dbus name
Is there another fcitx already running?
从最终进程数量看，系统里可能仍然只剩一个 Fcitx5 主进程，因此这个问题很容易被忽略。
真正的问题并不是长期存在两个 Fcitx5，而是：
登录阶段发生了第二次实例启动尝试，引入了初始化顺序竞争。
这种竞态可能影响：
- KWin Virtual Keyboard 所有权；
- Fcitx5 Wayland socket；
- D-Bus 注册顺序；
- Chromium 的 Wayland 输入上下文；
text-input-v3协议初始化；- 应用首次获得输入焦点时的状态同步。
为什么 Waydroid 崩溃后会恢复
日志时间线显示，Waydroid 事故发生后，并不是某一个输入法进程被简单重启，而是整套图形链路发生了重建：
- KWin 崩溃并重新启动；
- Plasma 相关组件重新建立；
- Brave 旧进程与 Wayland 合成器断开；
- 原 Fcitx5 实例退出；
- 新的 Fcitx5 重新取得 D-Bus 名称；
- 应用重新连接 Wayland 会话；
- 输入法上下文重新初始化。
因此，Waydroid并没有直接修复 Fcitx5。
它只是意外触发了一次比“关闭浏览器”更彻底的图形会话重置，使 Fcitx5、KWin 和应用重新建立了正确连接。
这也解释了为什么：
- 桌面崩溃后问题消失；
- 浏览器重启后仍然正常；
- 整机冷启动后问题再次出现。
修复方案
不建议删除系统文件：
/etc/xdg/autostart/org.fcitx.Fcitx5.desktop
因为它属于软件包管理范围，在其他桌面环境或 X11 环境中可能仍然有用途。直接删除还会导致软件包完整性检查报告文件缺失，并且软件升级后可能再次恢复。
更合适的方法是使用 XDG Autostart 的用户级覆盖机制。
创建用户级同名文件：
~/.config/autostart/org.fcitx.Fcitx5.desktop
内容如下：
[Desktop Entry]
Type=Application
Name=Fcitx 5
Hidden=true
这个文件的作用是：
- 保留系统级 autostart 文件；
- 仅对当前用户屏蔽传统启动路径；
- 不影响软件包管理；
- 不修改系统配置；
- 以后需要回滚时，只需删除用户级覆盖文件；
- KWin Wayland launcher 仍然保持正常工作。
需要注意，用户级文件名必须与系统级文件名完全相同，XDG Autostart 覆盖机制才会生效。
单变量 A/B 测试
为了确认双启动是否真的是根因，只进行了一项配置变化：
- 保留 KWin Wayland Input Method；
- 保留系统级 autostart 文件；
- 只加入用户级
Hidden=true覆盖； - 不修改其他 Fcitx5、KWin、Brave 或 Wayland 配置。
重启系统后，结果非常明确：
- 所有原本无法切换输入状态的应用全部恢复正常；
- 中文、英文、日语状态均可正常切换；
- 实际输入与状态显示一致；
- Brave 关闭后重新打开仍然正常。
随后进行了只读核验。
修复后的验证结果
修复后的系统状态为：
1. 只有一个有效 Fcitx5 主实例
系统中不再出现第二个普通 Fcitx5 启动尝试。
2. Fcitx5 由 KWin 启动
当前实例来自：
fcitx5-wayland-launcher --reopen
KWin 仍然指向：
/usr/share/applications/fcitx5-wayland-launcher.desktop
3. 传统 autostart 不再执行
对应的用户级 autostart service 不再生成或启动。
4. D-Bus 名称竞争消失
当前启动日志中不再出现：
Unable to request dbus name
也不再出现：
Is there another fcitx already running?
5. Wayland 输入法协议正常
唯一有效的 Fcitx5 实例正常持有：
org.fcitx.Fcitx5
并正常使用 Wayland native input method protocol。
最终结论
通过日志分析、配置审计、单变量修改、系统重启和修复后核验，可以确认：
KDE Plasma Wayland 下的输入法状态切换故障，是由 KWin Wayland Input Method 与传统 XDG Autostart 两条 Fcitx5 启动路径并存造成的。
传统 autostart 在冷启动阶段触发了第二个 Fcitx5 实例启动尝试，虽然第二个实例最终因 D-Bus 名称冲突而退出，但这一过程扰乱了输入法初始化顺序，导致部分原生 Wayland 应用中的输入状态异常。
使用用户级同名 desktop 文件设置：
Hidden=true
屏蔽传统 autostart 后，系统只保留 KWin Wayland launcher 路径，重复实例竞争消失，所有受影响应用恢复正常。
不需要继续深挖的部分
现有证据已经确认第二条传统 autostart 路径是故障的因果来源。
至于底层瞬间究竟发生在：
- D-Bus 名称竞争；
- Wayland socket 初始化；
- KWin Virtual Keyboard 所有权；
- Chromium
text-input-v3状态同步； - 应用首次焦点进入时的输入上下文注册；
目前没有必要继续细分。
从系统维护角度，根因已经确认，修复方案已经通过重启验证，不需要再通过制造崩溃或反复重启输入法进行实验。
维护建议
后续应保持以下状态：
~/.config/autostart/org.fcitx.Fcitx5.desktop
[Desktop Entry]
Type=Application
Name=Fcitx 5
Hidden=true
同时避免：
- 删除系统级 Fcitx5 autostart 文件；
- 再创建额外的 Fcitx5 systemd 用户服务；
- 在 shell 配置中手动执行
fcitx5 -d； - 同时启用多个 Fcitx5 自启动机制；
- 使用 Waydroid 或 KWin 崩溃作为输入法恢复手段。
这次故障也说明，在 Wayland 环境中，输入法能否正常工作，不仅取决于配置文件内容，还高度依赖合成器、D-Bus、桌面自启动与应用输入协议之间的初始化顺序。