光標(biāo)在 tmux 里憑空消失這種問題我前前后后遇到過不下十次。每次新入職一家公司只要我在新同事的終端里敲幾下 tmux 命令總能從某個(gè)角落把這種詭異的問題拽出來。先說一個(gè)反直覺的結(jié)論tmux 里光標(biāo)消失十有八九不是 tmux 的鍋而是某個(gè)程序把光標(biāo)藏起來之后忘了還回來。這個(gè)問題的迷惑性在于現(xiàn)象很嚇人但你的輸入一切正常打字、刪字、運(yùn)行命令都沒問題就是看不到那個(gè)一閃一閃的方塊或者豎線。有人慌到直接重啟終端、殺掉 tmux session其實(shí)大可不必。這篇文章我不會(huì)只給一個(gè)萬能命令了事。我會(huì)把光標(biāo)消失的幾類典型場(chǎng)景、從現(xiàn)象到根因的完整排查思路、以及我實(shí)測(cè)過有效的三層修復(fù)方案全部攤開講。無論你是剛接觸終端復(fù)用的小白還是已經(jīng)用 tmux 多年的老手都能從中找到對(duì)應(yīng)的解法關(guān)鍵是搞清楚背后的原理以后再遇到同類問題就能一眼定位。1. 先對(duì)號(hào)入座三類最常撞上的光標(biāo)消失現(xiàn)場(chǎng)我在各種環(huán)境里整理出一個(gè)規(guī)律tmux 里的光標(biāo)消失看著千奇百怪實(shí)際上能歸成三類。每一類的觸發(fā)時(shí)機(jī)、現(xiàn)象細(xì)節(jié)和元兇都不太一樣先別急著背命令對(duì)照下面的場(chǎng)景找到你屬于哪一種。1.1 場(chǎng)景 A整個(gè) pane 的光標(biāo)都消失了這個(gè)最嚇人。你正常在 shell 里敲命令一切正常然后突然發(fā)現(xiàn)提示符后面的光標(biāo)沒了。注意這里說的是整個(gè) pane 里所有程序的光標(biāo)都不見了不只是在 vim 里連在 shell 里敲ls -la都看不到光標(biāo)。這種情況我見過的最典型觸發(fā)路徑是在某一個(gè) pane 里跑了一個(gè)全屏 TUI 程序比如htop、btop、lazygit然后你沒有正常退出直接CtrlC或者關(guān)掉了終端窗口。再回到 tmux 里光標(biāo)就已經(jīng)沒了。還有一種是 tmux 開了多個(gè)窗口你在 A 窗口運(yùn)行某個(gè)程序把光標(biāo)隱藏切到 B 窗口時(shí) B 窗口的光標(biāo)也異常。這類問題的本質(zhì)是“狀態(tài)污染”隱藏光標(biāo)的控制序列已經(jīng)發(fā)出去了但對(duì)應(yīng)的顯示光標(biāo)的序列永遠(yuǎn)沒到。1.2 場(chǎng)景 B只有 vim / neovim 里的光標(biāo)不對(duì)勁第二種更隱蔽。你用 tmux 分屏左邊跑 vim右邊跑終端。終端那邊光標(biāo)完全正常但 vim 里光標(biāo)要么變成一個(gè)不閃爍的粗方塊要么徹底看不見。退出 vim 回到 shell光標(biāo)又正常了。這類問題通常不是 vim 的 bug而是vim 對(duì)終端能力的判斷出了問題。tmux 會(huì)給 pane 里的程序報(bào)一個(gè)特定的TERM環(huán)境變量vim 拿到這個(gè)值后會(huì)去 terminfo 里查終端支持哪些光標(biāo)能力。如果這個(gè)判斷出錯(cuò)vim 就不知道該用什么姿勢(shì)顯示光標(biāo)結(jié)果就是方塊、橫線、或者干脆不顯示。1.3 場(chǎng)景 C某個(gè) TUI 程序退出后光標(biāo)就回不來了第三類介于 A 和 B 之間。比如你在 tmux 里運(yùn)行fzf選文件按Esc取消然后發(fā)現(xiàn)光標(biāo)不見了?；蛘咴?tmux 里運(yùn)行htop用q正常退出但光標(biāo)偶爾不回來。這類問題的特點(diǎn)是“看運(yùn)氣”同一個(gè)程序有時(shí)退出正常有時(shí)光標(biāo)丟失。這背后的核心機(jī)制是程序在進(jìn)入全屏模式時(shí)會(huì)發(fā)送“隱藏光標(biāo)”的序列退出全屏模式時(shí)會(huì)發(fā)送“顯示光標(biāo)”的序列。但 tmux 本身不會(huì)替程序檢查這個(gè)配對(duì)是否完成。如果程序因?yàn)楸罎ⅰ⑿盘?hào)中斷、或者自身 bug 只執(zhí)行了隱藏沒有執(zhí)行顯示tmux 的 pane 里就永遠(yuǎn)停留在隱藏狀態(tài)。為了幫你更快對(duì)號(hào)入座我整理了一個(gè)表現(xiàn)象觸發(fā)操作最大嫌疑快速驗(yàn)證整個(gè) pane 都無光標(biāo)強(qiáng)殺 TUI 程序 / 切換窗口程序未恢復(fù)光標(biāo)在 shell 輸入tput cnorm僅 vim 內(nèi)光標(biāo)異常打開/退出 vimTERM 誤判 guicursorvim 內(nèi)執(zhí)行:echo t_SI單個(gè) TUI 退出后無光標(biāo)運(yùn)行 fzf/htop 后退出程序異常退出重跑一次并正常退出2. 從混亂中找規(guī)律一條能復(fù)用的排查鏈路很多人遇到光標(biāo)問題就直接開搜搜索關(guān)鍵詞換來換去折騰一小時(shí)問題依舊。我的經(jīng)驗(yàn)是與其急著找答案不如先建立一個(gè)分層模型然后逐層排除。這個(gè)過程只需要幾分鐘。2.1 先釘住分層模型終端、tmux、shell、程序各管一段一個(gè)程序的光標(biāo)顯示狀態(tài)其實(shí)經(jīng)過了層層傳遞。從最底層到最上層是這樣一條鏈終端模擬器iTerm2、Tabby、Windows Terminal、VS Code 集成終端等→ tmux → shellbash/zsh/fish→ 具體程序vim、htop 等。每一層都有能力改變光標(biāo)狀態(tài)。終端模擬器負(fù)責(zé)最底層的渲染tmux 作為終端復(fù)用器負(fù)責(zé)把 pane 的內(nèi)容渲染到終端模擬器上shell 和程序則是通過發(fā)送“控制序列”來控制上一層的光標(biāo)行為。所以排查的原則也明確從外層往內(nèi)層排除。先確認(rèn)終端模擬器本身沒問題再確認(rèn) tmux 轉(zhuǎn)發(fā)沒毛病最后才輪到 vim、htop 這些應(yīng)用。2.2 排查步驟從外層到內(nèi)層逐級(jí)排除第一步脫離 tmux 直接測(cè)試。新開一個(gè)終端窗口不要進(jìn) tmux直接在 shell 里運(yùn)行 vim 或 htop看光標(biāo)是否正常。如果正常說明終端模擬器和底層環(huán)境沒問題問題定位在 tmux 這一層或者 tmux 內(nèi)部的應(yīng)用環(huán)境。第二步在 tmux 里分別測(cè)試 shell 和 TUI 程序。先不啟動(dòng) vim就在 tmux 的 shell 里執(zhí)行tput civis sleep 1 tput cnorm如果第一條命令執(zhí)行后光標(biāo)消失、第二條執(zhí)行后光標(biāo)回來說明 tmux 本身能正常轉(zhuǎn)發(fā)光標(biāo)控制序列問題出在某個(gè)程序沒有發(fā)出第二條恢復(fù)序列。這個(gè)命令很安全放心用。第三步檢查 TERM 環(huán)境變量。在 tmux 里執(zhí)行echo $TERM正常情況下tmux 3.x 里應(yīng)該輸出tmux-256color或者screen-256color取決于你的配置。如果這里輸出的是xterm-256color或xterm甚至空值那 tmux 內(nèi)部的程序就會(huì)對(duì)光標(biāo)能力產(chǎn)生誤判。接著用 terminfo 查一下當(dāng)前 TERM 是否聲明了光標(biāo)控制能力infocmp $TERM | grep -iE cnorm|civis|Ss|Se正常輸出會(huì)包含cnorm顯示光標(biāo)和civis隱藏光標(biāo)等能力項(xiàng)。如果這里啥都沒有基本就鎖定了根因方向程序拿到一個(gè)殘疾的終端描述不知道該怎么控制光標(biāo)。第四步最小化復(fù)現(xiàn)排除個(gè)人配置的干擾。tmux 本身的插件、狀態(tài)欄、主題都可能導(dǎo)致光標(biāo)異常。用干凈配置啟動(dòng)一個(gè)調(diào)試會(huì)話tmux -L debug -f /dev/null new-session -s debug-f /dev/null表示不讀取任何配置文件-L debug用單獨(dú)的 socket避免和你日常的 tmux server 狀態(tài)混在一起。在這個(gè)干凈會(huì)話里復(fù)現(xiàn)一下光標(biāo)問題。如果這里正常說明是你主配置里某個(gè)設(shè)置觸發(fā)的如果這里也能復(fù)現(xiàn)才是更底層的終端交互問題。第五步查看當(dāng)前 pane 的最后執(zhí)行歷史。如果定位到是某個(gè) TUI 程序?qū)е碌目梢曰仡櫼幌履阍谶@個(gè) pane 里最后運(yùn)行的命令history | tail -20回想一下是否存在強(qiáng)殺程序的經(jīng)歷這對(duì)最終修復(fù)方向很有幫助。2.3 一個(gè) 3 分鐘定位法給大家一個(gè)簡(jiǎn)化的決策路徑方便日?？焖俣ㄎ蝗绻挥?vim 內(nèi)光標(biāo)異常→ 跳過去檢查TERM、guicursor和 vim 的終端支持配置。如果是運(yùn)行某個(gè) TUI 之后全 pane 都沒光標(biāo)→ 先執(zhí)行tput cnorm恢復(fù)然后檢查該程序的退出方式。如果剛打開 tmux 就沒光標(biāo)→ 優(yōu)先懷疑終端模擬器和 tmux 的渲染兼容性看看外層終端的渲染后端。這套鏈路走下來最多三分鐘就不會(huì)在茫茫配置里瞎猜了。3. 光標(biāo)到底是怎么丟的tmux 的轉(zhuǎn)發(fā)機(jī)制與三個(gè)核心原因很多人以為光標(biāo)是 tmux 弄丟的其實(shí) tmux 在大多數(shù)場(chǎng)景下只是個(gè)快遞員。它負(fù)責(zé)把每個(gè) pane 里程序發(fā)的控制序列原樣轉(zhuǎn)發(fā)到終端模擬器。但快遞員也有自己的規(guī)定和限制問題往往出在這里。3.1 光標(biāo)的生殺大權(quán)隱藏與顯示控制序列無論在哪個(gè)終端里控制光標(biāo)顯示/隱藏的核心就兩條 ANSI 轉(zhuǎn)義序列\(zhòng)033[?25l隱藏光標(biāo)對(duì)應(yīng) terminfo 里的civis\033[?25h顯示光標(biāo)對(duì)應(yīng) terminfo 里的cnorm很多全屏 TUI 程序htop、vim、fzf在進(jìn)入全屏模式時(shí)會(huì)先隱藏光標(biāo)避免光標(biāo)在界面里亂跑退出時(shí)再顯示光標(biāo)。這里的關(guān)鍵問題是隱藏和顯示必須成對(duì)出現(xiàn)。正常退出程序時(shí)比如 htop 里按q程序會(huì)依次發(fā)送顯示光標(biāo)和退出全屏模式的序列。但如果程序是被人為強(qiáng)殺CtrlC、kill -9或者自身崩潰它可能只來得及發(fā)送隱藏序列顯示序列永遠(yuǎn)沒發(fā)出去。tmux 作為快遞員不會(huì)自作主張幫你補(bǔ)發(fā)于是光標(biāo)就丟在了隱藏狀態(tài)。3.2 tmux 的轉(zhuǎn)發(fā)延遲escape-time 的坑tmux 還有一個(gè)特別容易引發(fā)光標(biāo)異常的機(jī)制就是escape-time選項(xiàng)。tmux 在收到ESCASCII 27即\033開頭的序列時(shí)會(huì)等待一段時(shí)間再?zèng)Q定如何處理這個(gè)等待時(shí)間就是escape-time默認(rèn)值是500 毫秒。問題在于vim 和 neovim 的光標(biāo)形狀切換序列通常以ESC開頭比如切換成橫線光標(biāo)的\033[2 q、切換成豎線光標(biāo)的\033[6 q。如果 tmux 在等待期把序列處理錯(cuò)了或者延遲過長(zhǎng)vim 在 insert 模式和 normal 模式之間切換時(shí)光標(biāo)形狀就會(huì)更新失敗。如果你在 tmux 里用 vim你會(huì)發(fā)現(xiàn)每次模式切換光標(biāo)反應(yīng)都慢半拍這個(gè)體驗(yàn)的根源就在escape-time。把它調(diào)低能明顯改善set -g escape-time 1010 毫秒是一個(gè)在兼容性和響應(yīng)速度之間比較平衡的值。有些追求極致的人會(huì)改成 0但我測(cè)試過某些程序發(fā)送的快速按鍵序列比如快速連按兩次 Esc有概率被誤判成 Alt 組合鍵所以 10 是我比較推薦的一個(gè)值。3.3 TERM 與 terminfo程序判斷你能顯示什么樣的光標(biāo)這是 vim/neovim 光標(biāo)異常的最常見根因。終端程序之間溝通“我支持哪些能力”靠的是TERM環(huán)境變量加 terminfo 數(shù)據(jù)庫。vim 啟動(dòng)時(shí)會(huì)檢查$TERM去 terminfo 里查這個(gè)終端類型是否聲明了Ss設(shè)置光標(biāo)樣式和Se恢復(fù)光標(biāo)樣式能力。如果查詢結(jié)果是不支持vim 干脆就不發(fā)送光標(biāo)樣式切換序列。默認(rèn)情況下tmux 會(huì)給內(nèi)部 pane 設(shè)置TERMtmux-256color或screen-256color取決于配置。如果你在 tmux.conf 里寫了類似set -g default-terminal screen-256color而系統(tǒng)里的 screen-256color terminfo 又比較舊沒有聲明Ss/Se那么 vim 就退化成了“默認(rèn)方塊光標(biāo)”模式。在某些字體和配色下這種方塊可能完全不顯示看起來就像光標(biāo)消失。更麻煩的是有人為了解決光標(biāo)問題在配置里胡寫一氣把 pane 的 TERM 搞成xterm-256color。這會(huì)導(dǎo)致 tmux 認(rèn)為外層終端支持全部 xterm 擴(kuò)展能力轉(zhuǎn)而把一組 tmux 自己都不一定能正確處理的能力發(fā)給外層終端反而引發(fā)更奇怪的渲染問題。在 tmux 內(nèi)部真的不需要手動(dòng)把 TERM 改成 xterm。3.4 崩潰/強(qiáng)殺程序帶走光標(biāo)的底層原因結(jié)合上面說的我們就能完整解釋場(chǎng)景 A 和 C 的底層鏈路TUI 程序啟動(dòng) → 發(fā)送\033[?25l隱藏光標(biāo)→ 進(jìn)入全屏繪制。程序被強(qiáng)殺kill -9、終端窗口直接關(guān)閉、系統(tǒng)崩潰→ 沒有執(zhí)行退出清理 →\033[?25h顯示光標(biāo)永遠(yuǎn)不會(huì)發(fā)出。tmux 里該 pane 的光標(biāo)狀態(tài)停留在隱藏態(tài)。你切到其他窗口再切回來tmux 渲染出來的 pane 里依然沒有光標(biāo)。終端模擬器通常有應(yīng)對(duì)方案一個(gè)前臺(tái)程序退出后終端會(huì)做一次狀態(tài)恢復(fù)。但 tmux 作為一個(gè)常駐進(jìn)程它的 pane 狀態(tài)不會(huì)因?yàn)橥鈱映绦蛲顺龆刂谩＿@就是為什么重啟終端能解決但重進(jìn) tmux 不一定能解決的原因——你殺掉的是外層終端tmux server 還留在舊的 pane 狀態(tài)里。4. 實(shí)測(cè)有效的修復(fù)手段止血、兜底、根治三層方案講完原理直接上干貨。我的建議是按順序做先止血讓光標(biāo)立刻回來再上兜底機(jī)制防止問題再次出現(xiàn)最后根據(jù)根因做針對(duì)性根治。4.1 第一層手動(dòng)止血不管哪種原因最快的光標(biāo)恢復(fù)命令是在出問題的 pane 里直接執(zhí)行tput cnorm如果tput不可用有些精簡(jiǎn)容器鏡像里沒裝 ncurses直接用原始轉(zhuǎn)義序列printf \033[?25h這條命令會(huì)和普通 shell 命令一樣執(zhí)行效果立竿見影不需要重啟 tmux、不用殺進(jìn)程。我個(gè)人習(xí)慣在 shell 配置文件里給它起一個(gè)短別名alias fixcursorprintf \033[?25h\033[0 q后面的\033[0 q是把光標(biāo)樣式重置為終端默認(rèn)同時(shí)處理了“光標(biāo)消失”和“光標(biāo)樣式異?！眱煞N情況。強(qiáng)殺 TUI 程序之后直接敲fixcursor就完事。4.2 第二層shell 鉤子自動(dòng)兜底手動(dòng)恢復(fù)終究不是長(zhǎng)久之計(jì)。更穩(wěn)的做法是每次 shell 顯示新提示符之前都強(qiáng)制發(fā)一次顯示光標(biāo)序列。這樣就算上一個(gè)程序把光標(biāo)藏了等你執(zhí)行完下一條命令、回到提示符時(shí)光標(biāo)也會(huì)自動(dòng)回來。bash 用戶在~/.bashrc里加PROMPT_COMMANDprintf \\033[?25h; $PROMPT_COMMAND注意這里的反斜杠轉(zhuǎn)義。PROMPT_COMMAND會(huì)在每次顯示主提示符之前執(zhí)行相當(dāng)于一個(gè)“每次命令執(zhí)行完的強(qiáng)制恢復(fù)”。zsh 用戶在~/.zshrc里加precmd() { printf \033[?25h }zsh 的precmd鉤子函數(shù)就是在每次打印提示符之前執(zhí)行的和 bash 的PROMPT_COMMAND是同一個(gè)時(shí)機(jī)。fish 用戶稍微特殊一點(diǎn)用事件函數(shù)function restore_cursor --on-event fish_prompt printf \033[?25h end這個(gè)兜底方案我用了很久實(shí)測(cè)下來不會(huì)對(duì)正常使用產(chǎn)生任何影響。你每次敲完命令提示符出現(xiàn)的那一瞬間屏幕上的光標(biāo)都會(huì)被強(qiáng)制拉回來。唯一需要注意的是如果你在 vim 的 insert 模式里vim 自己會(huì)管理光標(biāo)狀態(tài)shell 鉤子不會(huì)在 vim 運(yùn)行期間生效因?yàn)榇藭r(shí)根本不會(huì)觸發(fā) shell 提示符。4.3 第三層tmux 配置與 TERM 矯正接下來是根治層面的配置。我會(huì)把 tmux.conf 里和光標(biāo)行為相關(guān)的關(guān)鍵配置列出來每條都說明作用。# 降低 ESC 序列轉(zhuǎn)發(fā)延遲避免光標(biāo)樣式切換被吞 set -g escape-time 10 # 讓 tmux 內(nèi)部 pane 使用正確的終端描述 set -g default-terminal tmux-256color # 修正部分終端模擬器的 cnorm/civis 能力描述 set -ag terminal-overrides ,xterm-256color:cnorm\E[?25h:civis\E[?25l第一行解釋過了。第二行是讓 tmux 內(nèi)部 pane 的 TERM 露出完整能力這是 vim/neovim 正確顯示光標(biāo)的前提。第三行的terminal-overrides是給外層終端模擬器注意不是 pane 內(nèi)部補(bǔ)上光標(biāo)能力的明確定義防止 tmux 在極少數(shù)情況下讀到一個(gè)“缺胳膊少腿”的外層 terminfo 導(dǎo)致轉(zhuǎn)發(fā)異常。這里有一個(gè)容易踩的誤區(qū)terminal-overrides的第一段匹配的是外層終端模擬器的 TERM。也就是說如果你在 macOS 的 Terminal.app 里跑 tmux外層 TERM 是xterm-256color那就寫xterm-256color如果你在 Windows Terminal 里跑 WSL 再跑 tmux外層 TERM 可能不同需要按實(shí)際情況調(diào)整。如果拿不準(zhǔn)可以先執(zhí)行echo $TERM在 tmux 外面執(zhí)行看看當(dāng)前終端模擬器報(bào)的什么名字然后對(duì)應(yīng)調(diào)整。如果你的 tmux 版本在 3.2 以上還可以用terminal-features補(bǔ)齊外層終端的能力聲明set -ga terminal-features ,xterm-256color:focus,cstylefocus表示外層終端支持 focus event 上報(bào)cstyle表示支持光標(biāo)樣式切換。這兩項(xiàng)對(duì)于 neovim 0.8 的體驗(yàn)很重要它們能顯著減少光標(biāo)閃爍異常和樣式切換失效的問題。4.4 第四層vim / neovim 自己的光標(biāo)策略如果你確認(rèn)問題主要出現(xiàn)在 vim/neovim 里除了 tmux 側(cè)還需要在 vim 里顯式聲明光標(biāo)樣式策略。原因是 vim 的光標(biāo)顯示行為既依賴 terminfo 對(duì)終端的描述也依賴guicursor選項(xiàng)。默認(rèn)情況下vim 在終端里的光標(biāo)樣式受guicursor控制但很多發(fā)行版提供的 vim 配置里這個(gè)選項(xiàng)的值可能不完整。在.vimrc或init.vim/init.lua里加這幾行 vim 8.2 / neovim 通用 set guicursorn-v-c:block,i-ci-ve:ver25,r-cr:hor20 不等待 Esc 鍵的超時(shí)避免模式切換時(shí)光標(biāo)樣式更新延遲 set ttimeoutlen0第一行的含義是normal/visual/command 模式下用方塊光標(biāo)insert/替換模式下用豎線光標(biāo)25% 寬度replace 模式下用下劃線光標(biāo)20% 高度。這樣設(shè)置后vim 會(huì)主動(dòng)發(fā)送對(duì)應(yīng)的光標(biāo)控制序列而不是把決定權(quán)完全交給 terminfo。neovim 用戶還可以在init.lua里用更精確的方式設(shè)置vim.opt.guicursor n-v-c:block,i-ci-ve:ver25,r-cr:hor20 vim.opt.ttimeoutlen 0另外提一個(gè)經(jīng)常被忽略的點(diǎn)檢查一下你的TERM在 tmux 里是不是tmux-256color。如果之前有人為了修復(fù)問題把它改成了xterm-256color請(qǐng)改回來set -g default-terminal tmux-256color改完配置后記得重新加載tmux source-file ~/.tmux.conf并關(guān)掉現(xiàn)有 tmux server 后重開一個(gè) session因?yàn)閐efault-terminal只對(duì)之后新開的 pane 生效tmux kill-server tmux new-session4.5 驗(yàn)證是否生效的快速測(cè)試配置完之后用一個(gè)簡(jiǎn)單的組合命令驗(yàn)證效果。先在 shell 里執(zhí)行隱藏光標(biāo)的序列printf \033[?25l此時(shí)光標(biāo)消失。然后按一下回車讓 shell 觸發(fā)一次提示符刷新如果前面加了 shell 鉤子或者手動(dòng)執(zhí)行tput cnorm光標(biāo)恢復(fù)說明至少手動(dòng)恢復(fù)鏈路是通的。接著驗(yàn)證 vim在 tmux 里打開 vim分別在 normal 模式和 insert 模式下觀察光標(biāo)形狀正常情況是方塊和豎線切換。按vim的i進(jìn)入 insert 模式光標(biāo)應(yīng)該變成豎線按Esc回到 normal 模式光標(biāo)變回方塊。如果切換流暢、沒有延遲說明 escape-time 和 guicursor 都已生效。5. 容易被誤判的邊界情況以及如何防止下次再犯有些問題看著是 tmux 光標(biāo)消失但配置怎么調(diào)都不生效這時(shí)候大概率撞上了邊界情況。下面這幾種場(chǎng)景是我在不同環(huán)境里實(shí)際碰到過的。5.1 Windows Terminal、Tabby、kitty 等模擬器各有脾氣同樣的 tmux 配置在不同的終端模擬器上表現(xiàn)可能完全不同。比較典型的是 Windows Terminal WSL2 tmux 的組合早期版本存在光標(biāo)渲染 bug在 tmux 里頻繁出現(xiàn)光標(biāo)變白或者消失但問題根源在 Windows Terminal 的渲染后端。遇到這種情況先升級(jí)終端模擬器到最新版然后嘗試切換渲染后端。比如 Tabby 里可以切換 GPU / CPU 渲染模式Windows Terminal 在設(shè)置里可以切換渲染器。此外檢查終端模擬器自身的光標(biāo)設(shè)置比如是否開啟了“閃爍”或“使用塊狀光標(biāo)”因?yàn)槟M器層面的光標(biāo)樣式設(shè)置會(huì)和 tmux 應(yīng)用層的光標(biāo)樣式互相影響。kitty 的用戶還要注意一個(gè)問題kitty 有自己的一套鍵盤協(xié)議和光標(biāo)控制擴(kuò)展在 tmux 里使用時(shí)需要確保 kitty 的linux-kbd等特性不會(huì)和 tmux 沖突。保守的做法是在 tmux 外層設(shè)置一個(gè)標(biāo)準(zhǔn)的 TERM比如xterm-256color讓 tmux 對(duì)外層能力的判斷維持在常規(guī)范圍。5.2 嵌套 tmux 與外層終端的光標(biāo)疊加問題如果在一臺(tái)服務(wù)器上又套了一層 tmux比如本地 tmux 里 SSH 到遠(yuǎn)程服務(wù)器遠(yuǎn)程服務(wù)器又開了 tmux就會(huì)出現(xiàn) tmux 嵌套。這種情況下內(nèi)層 tmux 和外層 tmux 都會(huì)轉(zhuǎn)發(fā)和解釋控制序列光標(biāo)狀態(tài)疊加之后稍有不慎就會(huì)丟失。嵌套場(chǎng)景下的第一原則內(nèi)層 tmux 不啟用鼠標(biāo)捕獲或者至少保證內(nèi)外層的鼠標(biāo)/光標(biāo)控制策略一致。否則內(nèi)層 tmux 發(fā)出的鼠標(biāo)序列和外層 tmux 的響應(yīng)會(huì)互相干擾最終表現(xiàn)為光標(biāo)狀態(tài)混亂。第二原則把escape-time同時(shí)配置到內(nèi)外兩層 tmux 里。因?yàn)槊繉?tmux 都會(huì)對(duì)ESC開頭序列做一次延遲判斷只改一層另一層默認(rèn)的 500ms 延遲依然會(huì)拖慢光標(biāo)切換。5.3 插件和主題也會(huì)偷偷改光標(biāo)很多時(shí)候光標(biāo)問題的根源根本不是 tmux而是你的 vim 插件或終端主題。比如某些 vim 主題插件會(huì)在 colorscheme 加載時(shí)重置guicursor把你手動(dòng)設(shè)置的豎線光標(biāo)還原成某個(gè)不顯示的方塊某些狀態(tài)欄插件在渲染時(shí)發(fā)送的臨時(shí)光標(biāo)隱藏序列在異常情況下沒有恢復(fù)。遇到這種問題排查思路是“二分法”先把 vim 插件全部禁用用vim --clean啟動(dòng)一個(gè)不帶任何配置的 vim看光標(biāo)是否正常。如果正常再逐個(gè)啟用插件定位元兇。我遇到過一個(gè)很隱蔽的案例一個(gè) vim-airline 的擴(kuò)展會(huì)在退出 insert 模式時(shí)發(fā)送\033[?25l來隱藏某個(gè)狀態(tài)欄元素但它依賴的檢測(cè)邏輯在 tmux 里判斷失敗導(dǎo)致光標(biāo)被隱藏后沒人恢復(fù)。后來我在 vim 里加了一條自動(dòng)命令在離開 insert 模式時(shí)強(qiáng)制顯示光標(biāo)問題才徹底解決autocmd InsertLeave * set guicursorn-v-c:block這條命令的作用是每次離開 insert 模式都把光標(biāo)樣式強(qiáng)制設(shè)置為方塊。思路和 shell 鉤子類似相當(dāng)于給 vim 也加了一道“兜底”。5.4 防復(fù)發(fā)習(xí)慣給 TUI 一個(gè)體面的退出方式最后分享幾個(gè)我自己的使用習(xí)慣雖然看起來是“小細(xì)節(jié)”但對(duì)防止光標(biāo)問題復(fù)發(fā)非常有效。第一個(gè)習(xí)慣是TUI 程序盡量用它們自己的退出鍵。htop 用qfzf 用Esc或CtrlCfzf 有清理邏輯vim 用:q。不要隨便CtrlC強(qiáng)殺強(qiáng)殺雖然快但把清理邏輯也一起殺了。第二個(gè)習(xí)慣頻繁使用 tmux 的kill-pane功能來關(guān)閉已經(jīng)“臟”的 pane。如果一個(gè) pane 里光標(biāo)狀態(tài)已經(jīng)混亂與其一遍遍執(zhí)行tput cnorm不如直接Ctrlb x關(guān)掉這個(gè) pane然后新建一個(gè)。新 pane 的狀態(tài)是干凈的比任何恢復(fù)命令都省心。第三個(gè)習(xí)慣如果你經(jīng)常在同一臺(tái)機(jī)器上處理大量遠(yuǎn)程會(huì)話建議在 tmux 配置文件里加上這句set -g update-environment -r它的作用是當(dāng)重新 attach 一個(gè) tmux session 時(shí)把外層終端的環(huán)境變量同步進(jìn) pane順帶刷新一些終端狀態(tài)。雖然它不是為了光標(biāo)問題專門設(shè)計(jì)的但我實(shí)測(cè)過在某些重新 attach 后光標(biāo)異常的場(chǎng)景下這個(gè)配置能起到意外的緩解作用。我在實(shí)際使用中發(fā)現(xiàn)tmux 終端光標(biāo)問題的本質(zhì)就是“狀態(tài)泄漏”和“能力誤判”的組合。你不需要成為 ANSI 轉(zhuǎn)義序列專家只要理解隱藏/顯示光驅(qū)序列是對(duì)出現(xiàn)這一原則、tmux 只是轉(zhuǎn)發(fā)方而不是所有者再遇到這類問題就不會(huì)慌了。上面的配置和排查鏈路都是我這幾年攢下來的真實(shí)可用方案完全可以直接抄作業(yè)。