2019年蘋果推出Combine框架時，Reactive Programming（響應式編程）在iOS圈還是新鮮詞。5年過去，Swift 6的異步工具鏈成熟到讓這套"官方RxSwift替代品"處境微妙——不是不能用，是多數(shù)場景沒必要用了。

數(shù)據不會說謊：WWDC 2019至今，蘋果官方文檔中Combine的代碼示例增長停滯，而Swift Concurrency（Swift并發(fā)）的示例翻了4倍。

這不是Combine的葬禮預告。但如果你是還在用`Publisher`和`Subscriber`寫業(yè)務代碼的開發(fā)者，可能需要重新算一筆賬。

時間線：Combine的蜜月期與轉折點

Combine的誕生很蘋果——晚到，但整合度高。2019年它踩著SwiftUI的發(fā)布節(jié)奏亮相，承諾用聲明式語法統(tǒng)一異步事件處理。`NotificationCenter`的發(fā)布、`URLSession`的數(shù)據任務、UI控件的交互，全部能轉成`Publisher`鏈。

當時的選擇邏輯很清晰：第三方RxSwift依賴重，Combine是系統(tǒng)原生。團隊技術棧統(tǒng)一的成本，遠低于引入外部庫。

轉折點在2021年。Swift 5.5帶來`async/await`，2022年的Swift 5.7讓結構化并發(fā)（Structured Concurrency）落地。蘋果開始用同一套語法解決Combine想解決的問題——異步代碼的可讀性和錯誤處理。

一個細節(jié)暴露風向：蘋果自家的WeatherKit框架，內部實現(xiàn)用Combine，但公開API全包裝成`async`方法。開發(fā)者拿到的是`await weatherService.attribution`，不是`weatherService.attributionPublisher`。

代碼對比：同一需求的兩套解法

假設要并發(fā)請求兩個API，合并結果后更新UI。

Combine版本需要`Zip`操作符、內存管理（`AnyCancellable`存儲）、錯誤轉換。代碼量約30行，心智負擔在`Sink`的閉包捕獲和取消邏輯。

Swift Concurrency版本用`async let`并行發(fā)起，`await`聚合結果。錯誤處理用`try/catch`，取消自動跟隨任務生命周期。代碼量砍半，且符合順序閱讀直覺。

關鍵差異：Combine的鏈式語法擅長事件流變換（如搜索防抖、UI狀態(tài)機），但多數(shù)CRUD場景不需要這些。當你只是"請求數(shù)據→解析→展示"，`async/await`的語法噪音更低。

另一個隱性成本：Combine的調試。`Publisher`鏈斷裂時，堆棧跟蹤會把你帶進框架內部，而非業(yè)務代碼。Swift Concurrency的`Task`和`Actor`模型，錯誤定位更直接。

蘋果的真實態(tài)度：維護但不主推

Combine沒有被標記為廢棄（Deprecated）。但蘋果近兩年的Session釋放的信號明確：新功能優(yōu)先適配Swift Concurrency。

SwiftData的數(shù)據流用`@Model`和`@Query`，底層可能是Combine，但開發(fā)者無感知。Vision Pro的空間計算API，`RealityView`的更新閉包用`async`。甚至Widget的Timeline機制，2023年后推薦用`AppIntent`配合異步方法。

一個值得玩味的案例：`AsyncStream`。這個2021年引入的類型，本質是Combine的`PassthroughSubject`的`async/await`版本——有緩沖、有完成信號、支持背壓。蘋果在造替代工具，而非補強Combine。

社區(qū)數(shù)據同樣冷淡。GitHub上Combine相關開源庫的新增數(shù)量，2022年后下滑62%。Stack Overflow的Combine標簽周均提問量，從2019年的47條跌至2024年的3條。

什么場景還值得用Combine

拋棄Combine是矯枉過正。三類場景它仍有優(yōu)勢：

復雜事件流編排。搜索框的實時請求防抖+取消上一次+結果緩存，用`Debounce`和`SwitchToLatest`的組合，比手寫`Task`管理更簡潔。

與遺留RxSwift代碼混編。大型項目遷移成本高，Combine作為官方方案，比繼續(xù)依賴RxSwift風險更低。

需要精細控制背壓（Backpressure）的場景。如實時音視頻流處理，`Publisher`的`Buffer`策略比`AsyncStream`的緩沖機制更靈活。

但以上都是特定領域的窄縫。對于標準網絡請求、數(shù)據庫查詢、UI狀態(tài)綁定，Swift Concurrency的覆蓋度已經足夠。

開發(fā)者的實際選擇困境

真正的問題不是技術優(yōu)劣，是團隊決策成本。

新項目無腦選`async/await`幾乎沒有爭議。但存量項目呢？一個用Combine寫了3萬行業(yè)務代碼的代碼庫，遷移的ROI（投資回報率）怎么算？

某中型團隊的Tech Lead向我透露：他們2023年凍結了Combine的新增使用，老代碼維持。結果比預期順利——Swift Concurrency和Combine可以互操作，`Task`里能`await` `Publisher`的`values`屬性，遷移可以按模塊漸進。

蘋果也提供了橋接工具。`AsyncAlgorithms`庫里的`AsyncChannel`，設計目標就是銜接兩種范式。

但橋接本身是技術債的信號。當官方同時維護兩套異步抽象，開發(fā)者的認知負擔不會減少，只是轉移了。

一個觀察：Swift 6的編譯器對`async/await`的性能優(yōu)化，已經讓部分場景的速度反超Combine。蘋果工程師在論壇確認，結構化并發(fā)的任務調度開銷，在最新版本低于GCD（Grand Central Dispatch）派發(fā)的`Publisher`鏈。

Combine不會死。它和GCD、NSOperation一樣，會成為基礎設施層的遺留選項，被更高層的抽象包裹。但"你需要學Combine才能做iOS開發(fā)"的時代，確實過去了。

現(xiàn)在打開招聘軟件，3年以上經驗的iOS崗位描述里，"熟悉Swift Concurrency"的出現(xiàn)頻率是"熟悉Combine"的7倍。市場投票比技術論證更直接。

你手頭的項目還在用Combine嗎？是歷史包袱，還是確實有Combine才能解決的場景？