一、從 expect 到 Pexpect：一脈相承的“對話基因”

<i id='1516s'></i>

expect 誕生于上世紀九十年代，用 Tcl 寫成，專門解決“命令行交互無法腳本化”的痛點。核心思想只有三句：發送字符串、等待特定提示、再做下一件事。Pexpect 把這套思想原封不動搬進 Python，卻利用動態語言的反射能力，讓模式匹配、日志記錄、異常處理變得更貼近 Python 程序員的直覺。它并不依賴偽終端驅動的黑魔法，而是老老實實地 spawn 一個子進程，把標準輸入輸出錯誤重定向到管道，再用非阻塞讀寫與正則表達式完成“你說我答”的循環。理解了這層“管道+正則”的樸素實現，你就不會被“為什么捕獲不到顏色代碼”之類的問題困住：顏色只是終端轉義序列，同樣會被正則當成普通字符。

二、spawn：啟動子進程的“麥克風”

spawn 方法像按下錄音鍵，讓子進程開始說話。它接收的不只是字符串列表，也可以是單一命令行，甚至是一條需要 shell 解析的管道。關鍵點在于：  
1. 參數 shell=True 會調用系統解釋器，適合重定向、通配符等復雜場景，卻也帶來注入風險；  
2. 編碼問題必須在出生時就定好，否則后續讀取會遇到“半個漢字”的尷尬；  
3. 子進程默認繼承父進程的環境變量，但你可以通過 env 參數注入或屏蔽特定變量，避免“在我電腦能跑”的宿疾。  
spawn 返回的實例既是句柄也是上下文管理器，用 with 語句包裹可以確保子進程在異常時被收割，避免僵尸進程堆積。

三、expect：等待提示的“耳朵”

expect 方法負責“聽話”，它把子進程最近輸出的緩沖喂給正則引擎，直到某條模式匹配成功或超時。核心參數只有三個：模式列表、超時時間、搜索窗口大小。  
模式可以是字符串，也可以是預編譯的正則對象；若給列表，匹配到的索引會被返回，方便用 if-elif 做多分支。  
超時并非“命令執行總時長”，而是“兩次輸出之間的靜默上限”——理解這一點，就不會把數據庫導出的千兆文件當成“卡死”。  
搜索窗口默認 2000 字節，可隨場景調大或調小：日志刷屏場景宜大，交互極簡場景宜小，以節省內存。

四、send：發送應答的“嘴巴”

send 方法把字符串喂給子進程的 stdin，卻不會自動回車，需要手動追加換行符。  
sendline 在內部幫你補了換行，適合大多數“問完即答”的場合；  
sendcontrol 能模擬控制字符，例如 Ctrl+C、Ctrl+D、Ctrl+Z，用于中斷、退出、掛起；  
sendintr 專門發送中斷信號，比暴力 kill 更溫和，可觸發子進程的異常處理分支。  
注意：send 只是寫入管道，并不等待回顯，若你要“發完再確認”，需要再跟一次 expect。

五、before/after/match：捕獲結果的“記憶碎片”

當 expect 匹配成功，實例會留下三份現場證據：  
before 存放匹配點之前的所有輸出，相當于“問題”；  
match 存放匹配到的文本，相當于“關鍵詞”；  
after 存放匹配點之后的內容，相當于“余音”。  
利用這三段字符串，你可以解析 IP 地址、提取選擇菜單、甚至把交互日志整理成結構化數據。若模式里用了正則分組，match 對象還會附帶 .group(1) 之類接口，讓捕獲像切蛋糕一樣輕松。

六、交互節奏：prompt、超時與重試的“三角戀”

對話式自動化的難點不在“說一句”，而在“何時說”。  
prompt 是子進程輸出完提示符后的“靜默點”，代表“輪到你輸入”。若 prompt 本身隨上下文變化，就需要用正則分組提取動態前綴。  
超時是一把雙刃劍：太短會因網絡抖動誤判失敗，太長會讓批量任務堆積。  
重試策略需區分“命令語法錯誤”與“瞬時繁忙”：前者再試也徒勞，后者可指數退避。  
把三者做成一個小循環：發令→等提示→未出現→按退避時間重發，最多 N 次，就能把“偶發無響應”變成“健壯自動化”。

七、日志與調試：讓黑盒對話“可視化”

Pexpect 提供 logfile 參數，可把子進程所有字節流實時寫入文件，支持傳入二進制流或 TextIOWrapper。  
若想同時屏幕打印，可用 tee 模式或把 logfile 指向 sys.stdout.buffer。  
調試高階技巧：給 expect 設置 timeout=0，進入“步進模式”，每讀到一次輸出就暫停，方便手動驗證正則；  
或在關鍵 send 前后打印標記符，再在日志里搜索標記，快速定位“哪句問答”出錯。  
記住：日志是自動化運維的“行車記錄儀”，出事時它能幫你還原現場，避免“在我這兒明明能跑”的扯皮。

八、異常體系：從 EOF 到 TIMEOUT 的“信號塔”

Pexpect 把常見異常封裝成四類：  
TIMEOUT：期待的內容遲遲不來，可能是命令阻塞，也可能是正則寫錯；  
EOF：子進程提前退出，常見于密碼錯誤、命令不存在或核心轉儲；  
ExceptionPexpect：底層管道破裂，多發生在子進程被信號殺死；  
KeyboardInterrupt：用戶按 Ctrl+C，需要優雅關閉子進程并清理終端屬性。  
捕獲異常時，應先判斷類型，再提取 before 緩沖，往往能在“命令未找到”或 “Permission denied” 字樣里找到根因。  
最后務必 terminate 子進程，并 wait 回收退出碼，否則僵尸進程會像野草一樣悄悄蔓延。

九、并發與異步：讓多段對話“同時聊”

Pexpect 的 spawn 實例并非線程安全，若在多線程里共享，會出現“串臺”——輸入跑到另一段會話。  
做法有兩種：  
1.  每個線程獨享 spawn，通過隊列匯總結果；  
2.  用協程框架把 spawn 包裝成 async，底層把讀寫注冊到事件循環，實現“單線程偽并行”。  
無論哪種，都要注意 prompt 的正則不能貪婪匹配，否則一個長日志會把所有協程全部卡住。  
高階玩法：把對話狀態機拆成“發送-期待-回調”三元組，再用優先隊列調度，就能在同一進程內管理幾十條 SSH 會話，實現“批量刷配置”而無需額外腳本。

十、終端尺寸與顏色：假終端的“化妝術”

許多命令行工具會檢測 TTY 類型，若非終端則關閉彩色輸出或進入非交互模式。  
Pexpect 默認創建偽終端（pty），可設置 dimensions=(rows, cols) 模擬屏幕大小，讓 top、vim、less 等全屏工具正常繪制。  
但偽終端也會把顏色轉義序列（ANSI escape）一并輸出，若你打算用正則匹配，需要先把序列過濾或寫進模式。  
技巧：在 spawn 前 export TERM=dumb，或給子進程加 –no-color 參數，從源頭禁用顏色；  
若必須保留顏色用于后續展示，可用正則捕獲但不消費，讓 match 只關注文本核心。

十一、SSH、SFTP 與跳板機：網絡自動化的“三件套”

SSH 是最常見的對話場景，卻暗藏陷阱：  
首次連接會提示 “Are you sure you want to continue connecting?” 需要提前 send “yes”；  
密碼認證被策略禁用時，expect 永遠等不到 “password:” 提示，應優先使用密鑰代理；  
跳板機環境需兩次 spawn：先登錄跳板，再在本機執行 ssh 目標，注意二次 spawn 的 stdin/stdout 要連接到外層會話。  
SFTP 同樣基于 SSH，但提示符是 “sftp>”，上傳下載完成后要檢測 “100%” 或 “Done” 字樣，才能 send “quit”。  
若文件較大，建議改用 rsync over ssh，利用 –progress 的百分比輸出做 expect，能實時拿到傳輸速率并寫回日志。

十二、與配置管理工具共舞：Expect 不是“銀彈”

現代運維已出現大量聲明式工具，它們通過 API 推送配置，無需交互。  
Pexpect 的價值在于“遺留系統”：老舊網絡設備、封閉存儲管理口、第三方閉源安裝器，這些無法改代碼、無法裝代理的場景，才是 Expect 的用武之地。  
原則：能改配置管理就優先用聲明式；不能改才用對話式；一旦選擇對話式，就把 expect 腳本納入版本庫，與 Ansible、Terraform 放在同一目錄，接受 Code Review 和自動化測試。  
記住：Expect 是“最后三公里”的擺渡車，而不是整條高速公路。

十三、測試與Mock：讓“聊天”也能單元測試

expect 腳本看似只能連真環境，實則可用 “echo 管道” 技術做 Mock：  
寫一段 shell 函數，按順序輸出提示并讀標準輸入，再用 Pexpect 連接，就能在 CI 里跑回歸。  
高階方案：用 Python 的 pty 模塊自己 spawn 一個偽終端，對端運行一個 while read 循環，根據收到的字符串決定回顯內容，實現完全可編程的“對話樁”。  
這樣，一旦設備 CLI 升級，只需更新 Mock 腳本，就能在本地提前發現正則失效，避免“到現場才翻車”。

十四、性能邊界：緩沖區、大日志與千兆導出

Pexpect 默認把子進程輸出讀入內存，若遇到千兆級別的 SQL 導出，緩沖區會無限膨脹，最終導致宿主機 OOM。  
緩解策略：  
1.  在 expect 循環里不斷把 before 寫入磁盤，再清空緩沖區；  
2.  對只關心進度條的場景，用 “.*\r” 模式匹配行尾回車，再提取百分比，丟棄中間文本；  
3.  若確認無需解析，可把 stdout 直接重定向到文件，expect 只負責發送，避免讀回。  
記住：Expect 擅長“對話”，不擅長“大數據搬運”；遇到文件級傳輸，優先用專用工具，再把結果文件讀回來解析。

十五、安全箴言：密碼、密鑰與日志脫敏

expect 腳本常在日志里留下完整交互內容，若包含密碼，會被明文寫入文件。  
做法：  
1.  用 getpass 模塊在本地讀取密碼，再 send，禁止硬編碼；  
2.  在 logfile 寫入前，重寫過濾器，把密碼段替換為 ****；  
3.  對高敏環境，關閉 logfile，改用 syslog 轉發，只記錄命令階段，不記錄具體內容。  
最后，把 expect 腳本權限設為僅所有者可讀，避免 CI 日志被搜索引擎爬蟲公開，釀成“密碼門”。

十六、維護與傳承：把“對話”寫成狀態機文檔

expect 腳本往往只有作者本人能看懂，后期設備升級，新人面對失效的正則如讀天書。  
最佳實踐：  
1.  在腳本頭部用注釋畫出“提示-應答”狀態圖，標明每一步期望的正則、可能的異常分支；  
2.  把魔法正則拆成常量，并給予語義命名，例如 PASSWORD_PROMPT、SHELL_PROMPT；  
3.  在 README 里記錄設備型號、系統版本、CLI 特征，方便后人升級時快速定位差異。  
一句話：expect 腳本是“可執行文檔”，寫給人看，其次才是給機器跑。

尾聲：讓終端對話成為可編排的樂章

Pexpect 不是高深莫測的黑魔法，它只是一把“會說話的扳手”，把原本只能人工敲打的交互場景，變成可版本化、可測試、可重放的 Python 代碼。掌握它，你便能穿越“封閉 CLI” 的荊棘叢，把老舊系統納入現代自動化體系；也能在批量運維的深夜，不再守著屏幕一個個輸入 yes，而是讓腳本代勞，自己去泡一杯真正的咖啡。愿你在下一次遇到“只能人工聊”的命令行時，想起這篇長文，然后微笑著寫下幾行 expect，把重復、瑣碎、易錯的對話，變成沉穩、精確、可審計的自動化樂章。