Rust 2024 面試：async closure 解決了什麼問題？

題幹與適用場景

你維護一個 Rust 1.85 服務，需要把回呼交給非同步重試器。回呼要借用呼叫者提供的緩衝區，執行非同步 I/O，並支援不同借用生命週期。請比較 async || {} 與 || async {}，說明 AsyncFn、生命週期、捕獲、取消和遷移策略。

面試官考察點

• 是否理解 async closure 回傳的 future 可以借用 closure 捕獲的資料。
• 是否能用 AsyncFn、AsyncFnMut、AsyncFnOnce 表達高階非同步回呼。
• 是否區分 future 被建立、被 poll、被取消時的所有權和生命週期。
• 是否給出版本遷移、邊界測試和執行期資源清理方案。

回答前需要澄清的問題

1. 回呼需要重複呼叫、修改內部狀態，還是只呼叫一次？決定 AsyncFn trait。
2. 輸入是擁有的資料還是短生命週期借用？API 是否要求回呼在呼叫期間完成？
3. 取消發生在等待 I/O 時還是重試器退出時？外部資源如何清理？
4. MSRV 是否已升到 Rust 1.85，依賴是否支援 Rust 2024？

30 秒回答框架

|| async {} 是普通 closure 回傳 async block，inner future 不能像 async closure 一樣借用 closure 捕獲；Rust 1.85 的 async || {} 直接表達非同步呼叫，標準庫提供 AsyncFn 系列 trait。設計 API 時先按呼叫次數選 trait，明確輸入借用只在 future 完成前有效，取消由 future 的 drop 觸發清理。遷移先升級工具鏈和 edition，使用 cargo fix 做保守改寫，再用編譯器、Miri 或執行期測試驗證借用、重試和取消。

分步驟深入解答

1. 比較兩種寫法

普通 closure 回傳一個 future：

let old = |buf: &mut Vec<u8>| async move { buf.push(1); };

async closure 把非同步呼叫本身作為 closure 契約：

let new = async |buf: &mut Vec<u8>| { buf.push(1); };

關鍵差異是能否表達「每次呼叫都產生一個與輸入相關的 future」。前一種寫法在高階泛型約束中容易遇到返回 future 生命週期無法統一；後一種由 AsyncFn traits 表達這個關係。

2. 選擇 AsyncFn trait

只讀且可重複呼叫的回呼優先 AsyncFn；需要修改捕獲狀態且可重複呼叫時用 AsyncFnMut；消費捕獲資源且只呼叫一次時用 AsyncFnOnce。不要只因函式回傳 future 就把所有回呼框成 BoxFuture，那會錯誤排除短借用。

3. 生命週期與捕獲

輸入借用必須活到 future 完成或被 drop。回呼不應把借用存入 'static 工作，也不應在重試器把 future 放入長期佇列後繼續使用已失效的 buffer。若確實需要背景執行，先複製或轉移擁有的資料，再讓工作擁有自己的生命週期。

4. 取消和資源釋放

Rust 沒有強制非同步取消協定；通常透過 future 被 drop 表示取消。I/O 封裝要在 drop 或明確 cancellation token 下關閉 socket、釋放鎖和刪除暫存檔。重試器不能同時 poll 同一個 future，也不能在取消後繼續使用回呼寫入的狀態。

5. 重試與副作用

只有冪等操作能自動重試；非冪等 I/O 需要 request id、交易或補償動作。每次重試重新建立 future，記錄 attempt、錯誤和取消原因。若回呼已提交外部副作用，重試前查詢結果或使用冪等鍵，避免重複扣款或寫入。

6. 遷移與驗證

先把 CI、開發環境和 MSRV 升到包含 async closures 的 Rust 1.85，再依 Rust 2024 指南遷移。cargo fix --edition 只提供保守修改，不能取代語意審查。測試覆蓋短借用、可變捕獲、重複呼叫、future drop、逾時、重試和各目標平台編譯。

高品質示範回答

我會先按回呼是否重複呼叫和是否消費捕獲選擇 AsyncFn、AsyncFnMut 或 AsyncFnOnce。async || 直接表達非同步 closure，因此每次呼叫產生的 future 可以與輸入借用關聯；|| async {} 在高階泛型中通常難以表達這種借用關係。API 不把短借用 future 存成 'static，背景工作改為接收擁有的資料。取消透過 future drop 或 cancellation token 清理 I/O 和鎖；重試只對冪等操作開放，並記錄 attempt 和 request id。遷移到 Rust 1.85 後用編譯器、Miri 和執行期測試覆蓋生命週期、重試與取消。

常見錯誤

• 說兩種寫法完全等價 → 忽略捕獲借用和高階 trait → 用短借用回呼驗證生命週期。
• 所有回呼都要求 'static → 限制合法同步呼叫 → 區分前台借用和背景擁有資料。
• 取消只設布林值 → I/O 仍持有鎖或 socket → 讓 drop 和 cancellation token 都有清理路徑。
• 非冪等操作無限重試 → 外部副作用重複 → 使用 request id、查詢或補償。
• 把 cargo fix 當完整遷移 → 語意和 MSRV 風險未驗證 → 加入跨平台編譯和行為測試。

追問及應對

為什麼不把 callback 的 future 統一裝箱為 'static？

這會丟失與輸入借用相關的生命週期，合法的短借用回呼將無法通過型別檢查。只有真正交給長期背景工作的資料才應先擁有化，再使用 'static。

AsyncFnMut 回呼被並發呼叫會怎樣？

它表達可變捕獲，但不自動提供並發安全。重試器要串行呼叫、加鎖或讓每次呼叫擁有獨立狀態，不能同時持有兩個可變借用。

future 在 I/O 中途被 drop，如何證明清理完成？

為資源封裝 Drop 或明確取消路徑，測試逾時和工作取消，並檢查連線、鎖、暫存檔和外部 request id 的最終狀態。