為什麼 Rust Workers 需要 panic unwind，而不只是 a…
Rust Workers 要真正可靠，不能只靠 abort recovery；必須同時支援 panic unwinding，才能在失敗後保住狀態並安全恢復。
Rust Workers 要真正可靠，必須同時支援 panic unwinding 與 abort recovery，否則一次失敗就可能污染整個執行個體。
我站在這一邊：對 Rust Workers 而言，panic unwind 不是錦上添花，而是處理有狀態工作負載的基本能力；abort recovery 只能當最後防線，不能當主方案。Cloudflare 已經把問題說得很清楚：在共享執行個體裡，一次未處理的 Rust abort 不只會打掉當前請求，還可能影響鄰近請求，甚至讓後續新請求持續出錯。
第一個論點：沒有 unwind，就沒有真正的狀態保護
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
如果你的 Worker 內部保存了可觀的記憶體狀態，像 Durable Objects 這類模式，一次 panic 不是單一請求失敗而已，而是整個執行個體的狀態連續性被打斷。對這種 workload 來說，單純重建應用不等於恢復，因為你已經失去那個 request 之前累積的上下文。
WebAssembly Exception Handling 在 2023 年獲得主流引擎支援，這件事很關鍵。當 Rust 能用 panic=unwind，解構子會正常執行，catch_unwind 也能工作，Rust 與 JavaScript 的邊界就能把失敗轉成可處理的 PanicError，而不是把執行個體留在未定義狀態。這不是語法糖，而是把「失敗」和「資料損壞」分開。
第二個論點：abort recovery 仍然必要，但它解決的是另一種問題
即使有 unwind，abort 依然會出現，最典型的就是 out-of-memory。abort 本來就無法展開堆疊，也就無法保留當前執行狀態，所以平台仍需要一條硬恢復路徑，能偵測 abort、阻止壞狀態擴散，並確保下一次操作從有效基線開始。
Cloudflare 的做法不是把問題包裝成「重試就好」，而是加上 abort hooks、reentrancy guards 與 exception tagging，讓 runtime 能分辨真正的 abort 和跨邊界傳來的外部例外。這很重要，因為 JavaScript 可以在任意深度重新進入 Wasm。少了這些機制，一個壞 stack frame 就可能污染同一個 instance 裡的其他工作。
反方可能怎麼說
最強的反對意見是：這些複雜度應該留在應用層，不該塞進工具鏈。工程師可以自己包住高風險操作、在失敗後重啟 Worker，或乾脆設計成無狀態服務。從這個角度看，unwind、exception tag、reset hooks 都像是為了補救本來就該避免的架構問題。
另一個真實顧慮是可攜性。WebAssembly exception handling 曾經有多種變體，Rust 在某些 target 上也還保留舊行為，不同 runtime 的支援節奏未必一致。若生態系還在分裂，押注 panic recovery 看起來像把可靠性綁在一個尚未完全收斂的標準上。
但這個反對意見忽略了核心事實：共享執行個體本來就是共享狀態，單靠應用層紀律無法把 poisoned instance 完全隔離。當平台允許並發任務、JS 與 Wasm 深度交錯、又有長壽命記憶體狀態時，失敗語意本來就屬於 runtime 與工具鏈。Cloudflare 把它往上游推是對的，因為「失敗就整個重啟」對有狀態系統根本不是完整答案。
你能做什麼
如果你是工程師，別再把 panic=abort 當成預設安全解法；在有狀態邏輯上改用 unwind，明確劃出 exported boundary，並把 abort recovery 視為最後防線而不是可省略功能。如果你是 PM 或創辦人，直接問你的 Wasm stack：一次壞請求會不會拖垮其他工作、會不會丟掉記憶體狀態、會不會讓後續請求繼續錯下去。只要答案有一個是「會」，可靠性就還沒做完。