supervisorScope不該當常規方案：掘金長文剖析Android協程異常處理的常見誤區

掘金用戶「潛龍勿用之化骨龍」於2026年10月18日發表一篇約8分鐘閱讀量的Android協程實踐文章，核心主張是：不應將supervisorScope作為Android業務代碼中的常規異常處理或防崩方案。文章建議的替代做法，是在Repository資料邊界消化並標準化可預期異常，讓上層透過顯式結果處理成功與失敗兩種路徑。本臺以下以回顧角度整理該文的論點輪廓與可核實細節。

文章的第一層論點：supervisorScope改變的是取消關係

文章先回到Kotlin結構化並發的基礎規則。普通的coroutineScope遵循失敗傳播機制：一個子協程失敗時，父協程被取消，其他子協程連帶被取消，異常繼續向上傳播。作者以並行載入用戶資料與推薦內容為例，若其中一個任務拋出異常，另一個任務也會一併終止。

supervisorScope改變的是子協程之間的取消關係。在其中一個子協程失敗時，兄弟協程不會被自動取消。作者據此強調其定位：supervisorScope隔離的是子協程之間的失敗取消，既不是處理異常的機制，也不是保證應用不崩潰的方案。

第二層論點：supervisorScope無法避免Crash

文章舉出一段具迷惑性的常見寫法：在viewModelScope.launch注入CoroutineExceptionHandler，內部以try/catch包住supervisorScope，再於其中啟動兩個子協程，一個延遲後拋出RuntimeException，另一個正常完成並處理CancellationException。這段程式碼帶出三個結論。

第一，外層try/catch對獨立子協程內部未處理的異常形同虛設，異常向上冒泡時外層感知不到。第二，supervisorScope只隔離取消、不隔離異常，子協程1崩潰時子協程2確實順利跑完，但異常本身並未消失。第三，必須注入CoroutineExceptionHandler才能兜底；若移除handler，即使子協程2未受影響，子協程1的未處理異常仍會向上傳播，最終導致整個Android應用崩潰。

作者指出，Android與部分後端環境不同，只要有未捕獲異常冒泡到根節點，應用就會直接崩潰。因此不能把supervisorScope當成防止異常向上傳播、防止應用崩潰或省略錯誤處理的手段。

第三層論點：問題根源在資料層異常穿透

文章將根源指向資料層設計。網路超時、服務端異常、數據解析失敗、資料庫讀取失敗、檔案存取失敗、系統服務不可用等，都屬於應用運行中可預期的失敗。來源摘錄在此處中斷，原文後續關於Repository如何標準化異常、上層如何以顯式結果接住失敗的具體做法，本臺無法自現有材料核實完整內容，不予轉述。

訊源性質與可核實邊界

需要說明的是，此文屬於單一開發者的技術觀點文章，目前未見Kotlin官方文件或Google官方指南的直接對照引述，其「不應作為常規方案」屬作者本人的工程判斷。讀者若要驗證文中的協程行為，可對照Kotlin協程官方文件中關於結構化並發、監督作業（supervision）與CoroutineExceptionHandler的說明，兩者涉及的機制名稱與行為描述可相互印證。

類似的單一訊源技術長文整理，可參考本臺先前對主流網站瀏覽器端為何不採用JWT一文的處理方式：整理論點、標明訊源性質並保留可核實的邊界。至於Android端的程式碼保護議題，先前整理的Android代碼加固技術文整理亦屬同一平臺的開發者實踐記錄。

依現有資料，該文論點輪廓已如上述；其主張是否適用於個別專案的異常邊界設計，仍取決於各專案的實際架構與失敗場景，本文不作評斷。