概念位置

機制與 --predict=never 的關法見 mosh 本地回顯預測。

雙寬字：一個字兩格

終端是一個固定欄寬的格子畫布，游標位置、換行、重繪都以「第幾格」計算。CJK 字元佔兩格，任何要定位游標或重畫某一行的邏輯都得正確地把中文算成寬度 2。多數終端與 server 端的 shell（bash / zsh）處理雙寬字是正確的，問題出在中間有「猜寬度」的層時。

顯示：哪一層算錯寬度就錯位

伺服器端把中文印出來通常沒問題（shell 知道寬度）。會錯位的是加了預測的連線層——mosh 的本地回顯預測要在客戶端先猜你打的字怎麼佔位，撞上雙寬字容易算錯、游標與行重繪錯位。典型症狀是輸出正常、只有正在編輯的輸入行亂（輸出不經預測、輸入行才有）。

輸入：raw 模式擋 IME 組字、貼上繞過

CJK 即時輸入需要輸入法（IME）走「組字 → 選候選字 → 上屏」的多步驟流程，而終端為了把每個按鍵即時送到遠端、常以 raw 模式接收輸入、擋掉了 IME 的組字介面。結果是：在終端裡輸入法切不到中文 / 打不出來，但這跟編碼無關——把在別處組好的中文貼進終端能正常送出。所以判別點是「貼得進、打不出」：貼上繞過了即時組字流程、證明編碼與傳輸都 OK、卡的純粹是終端的即時組字支援。

判讀訊號 / 邊界

• 貼上能送、即時打不出 → 是終端的 IME 即時組字支援問題、不是編碼、不是鍵盤沒中文。繞法：他處組字後貼上、或用 ASCII。
• 即時打得出但畫面錯位 → 是顯示層（多半是 mosh 預測撞雙寬字）→ 關預測或改用純 SSH。
• client 對 CJK 即時輸入的支援差異很大（有些終端 app 有實驗性 CJK 開關、有些完全不支援），要各自實測；這是行動終端的普遍弱點、不是單一 client 的 bug。