一個 Ctrl+Space，卡了一整晚
antiX 26 × fcitx5 × 新酷音：從懷疑人生到徹底搞懂
我有一台 Acer Aspire 4745G，第一代 i5，4GB RAM，說老不老，說新不新。 它的任務是跟我跑現場——去客戶公司做網路勘查，掃設備、抓封包、出報告。
為了讓這台老筆電跑得動勘查工具，我裝了 antiX 26——一個極度輕量的 Linux 發行版。 裝完之後一切都好，只剩一件事：打不了中文。
「這有什麼難的？」——我當時這樣想
在 Windows 上裝中文輸入法是五分鐘的事。Linux 嘛，查一下文件，跑幾行指令，應該也差不多吧。
結果我低估了這件事。
先裝 fcitx5，按照網路教學一步一步來，裝完重開機——Ctrl+Space，沒反應。 換 fcitx4，一樣。換 ibus，還是一樣。 三套輸入法框架，全部裝了又刪，刪了又裝，環境變數在系統裡留下一堆殘骸互相打架。
讓 Google Search AI 幫我試了四種不同版本，全都失敗。
「是不是 antiX 根本就不支援中文輸入？」
「還是我哪個步驟做錯了？」
「還是這台機器有什麼特殊問題？」
這種時候最消耗心力——不是累，是不知道問題出在哪裡，所以不知道從哪裡修。
換個工具，換個思路
後來我換了方法：不再自己亂試，而是讓 Claude Fable 5 協助我做系統性的診斷。
做法很直接——先寫一支診斷腳本，把系統狀態全部挖出來： 目前裝了哪些輸入法套件、環境變數是什麼值、Display Manager 是哪個、 PAM 設定長什麼樣、之前安裝失敗的 dpkg log 留了什麼痕跡。 然後把報告整份丟給 AI，讓它幫我拆解。
分析結果讓我有點意外——問題不是一個，是四個。四個不同子系統的設計決策， 剛好全部疊在一起，讓每一個「正確步驟」都失效。
為什麼「正確的步驟」會全部失效？
要解釋這件事，得先說 Linux 桌面的輸入法是怎麼運作的。 下面這張圖標出了這次排障中，每一個失效點的位置：
✗ 不讀 /etc/environment
✗ 21_ibus < 23_fcitx5，選錯
✗ export 不傳遞（fork）
antiX 的 startup 是 fork 執行，不是 source，export 只活在自己的子 shell 裡。
PAM 設定缺少 read_env=1，這個在其他發行版百試百靈的做法，在 antiX 上完全無效。
ibus 套件已 purge，但只要 libibus 函式庫還在，它就永遠排在前面被選中。
優先級高於所有環境變數，直接繞過整條污染路徑。
最有趣的一條線索
排障過程中有一個讓我印象很深的推理過程。
驗證環境變數的時候，看到這樣的結果：
XMODIFIERS=@im=ibus
QT_IM_MODULE=ibus
SDL_IM_MODULE=fcitx ← 這個不一樣
前三個是 ibus，但 SDL 是 fcitx。
翻開 21_ibus.rc 的原始碼，裡面有一行明確的註解：
ibus 刻意不設定 SDL_IM_MODULE。
這個「例外」反過來告訴我們：覆蓋掉 GTK/QT/XMODIFIERS 的兇手， 正是 im-launch 的 ibus fallback——不是 startup，不是 shell rc， 而是一個本來應該「自動選最好的」機制，在特定條件下選錯了。
這就是為什麼這種問題很難靠「再試一次」解決——每一層看起來都正確， 問題藏在各層之間的縫隙裡。需要的不是更多嘗試，而是把整條路徑都攤開來看。
最後怎麼修好的
修復腳本共十個步驟，其中最關鍵的三個：
dbus-update-activation-environment
把正確的 fcitx 變數注入 D-Bus session，讓終端機和 browser 的 Ctrl+Space 恢復正常。
~/.config/gtk-3.0/settings.ini 加入 gtk-im-module=fcitx
GTK3 的設定檔優先級高於所有環境變數。geany、所有 GTK3 app 的 Ctrl+Space 一次修好。不需要跟環境變數爭，直接繞過整條污染路徑。
~/.gtkrc-2.0 加入 gtk-im-module=”fcitx”
GTK2 app（leafpad、roxterm）另有獨立設定路徑，同樣需要一行強制指定。
現在的狀態
這台老筆電現在可以正常打中文了。geany、leafpad、Firefox、終端機， Ctrl+Space 全部正常切換新酷音。整件事從開始排查到解決，花了一個晚上。
這件事讓我想到的
這次讓我感觸比較深的，不是技術本身，而是排障的方式。
在這之前，我的做法是「查到一個解法就試」，試了不行再查下一個。 這種方式在問題單純的時候沒問題，但遇到多層交互的故障， 愈試愈亂，因為每次嘗試都可能在系統裡留下新的殘留。
換成「先完整診斷、再系統性修復」之後，整個過程清晰很多。 而且最後產出的腳本是可以複用的——下次再裝 antiX，十分鐘搞定， 不用再走一遍這條路。
這台筆電的任務是去客戶現場做勘查。現場不能有「等我回去查一下」的狀況。 所以每一個工具都要可靠，包括輸入法。 花一個晚上把這件事搞清楚，值得。
完整的 Root Cause Analysis 報告、修復腳本（含全新安裝版）， 都附在本文後面供下載。有在用 antiX、MX Linux 或其他輕量 Debian 的朋友， 如果也卡在中文輸入法，歡迎直接取用。
Comments