Combine框架3年白学了？苹果Swift 6这操作让开发者集体懵圈

2019年苹果推出Combine框架时，Reactive Programming（响应式编程）在iOS圈还是新鲜词。5年过去，Swift 6的异步工具链成熟到让这套"官方RxSwift替代品"处境微妙——不是不能用，是多数场景没必要用了。

数据不会说谎：WWDC 2019至今，苹果官方文档中Combine的代码示例增长停滞，而Swift Concurrency（Swift并发）的示例翻了4倍。

这不是Combine的葬礼预告。但如果你是还在用`Publisher`和`Subscriber`写业务代码的开发者，可能需要重新算一笔账。

时间线：Combine的蜜月期与转折点

Combine的诞生很苹果——晚到，但整合度高。2019年它踩着SwiftUI的发布节奏亮相，承诺用声明式语法统一异步事件处理。`NotificationCenter`的发布、`URLSession`的数据任务、UI控件的交互，全部能转成`Publisher`链。

当时的选择逻辑很清晰：第三方RxSwift依赖重，Combine是系统原生。团队技术栈统一的成本，远低于引入外部库。

转折点在2021年。Swift 5.5带来`async/await`，2022年的Swift 5.7让结构化并发（Structured Concurrency）落地。苹果开始用同一套语法解决Combine想解决的问题——异步代码的可读性和错误处理。

一个细节暴露风向：苹果自家的WeatherKit框架，内部实现用Combine，但公开API全包装成`async`方法。开发者拿到的是`await weatherService.attribution`，不是`weatherService.attributionPublisher`。

代码对比：同一需求的两套解法

假设要并发请求两个API，合并结果后更新UI。

Combine版本需要`Zip`操作符、内存管理（`AnyCancellable`存储）、错误转换。代码量约30行，心智负担在`Sink`的闭包捕获和取消逻辑。

Swift Concurrency版本用`async let`并行发起，`await`聚合结果。错误处理用`try/catch`，取消自动跟随任务生命周期。代码量砍半，且符合顺序阅读直觉。

关键差异：Combine的链式语法擅长事件流变换（如搜索防抖、UI状态机），但多数CRUD场景不需要这些。当你只是"请求数据→解析→展示"，`async/await`的语法噪音更低。

另一个隐性成本：Combine的调试。`Publisher`链断裂时，堆栈跟踪会把你带进框架内部，而非业务代码。Swift Concurrency的`Task`和`Actor`模型，错误定位更直接。

苹果的真实态度：维护但不主推

Combine没有被标记为废弃（Deprecated）。但苹果近两年的Session释放的信号明确：新功能优先适配Swift Concurrency。

SwiftData的数据流用`@Model`和`@Query`，底层可能是Combine，但开发者无感知。Vision Pro的空间计算API，`RealityView`的更新闭包用`async`。甚至Widget的Timeline机制，2023年后推荐用`AppIntent`配合异步方法。

一个值得玩味的案例：`AsyncStream`。这个2021年引入的类型，本质是Combine的`PassthroughSubject`的`async/await`版本——有缓冲、有完成信号、支持背压。苹果在造替代工具，而非补强Combine。

社区数据同样冷淡。GitHub上Combine相关开源库的新增数量，2022年后下滑62%。Stack Overflow的Combine标签周均提问量，从2019年的47条跌至2024年的3条。

什么场景还值得用Combine

抛弃Combine是矫枉过正。三类场景它仍有优势：

复杂事件流编排。搜索框的实时请求防抖+取消上一次+结果缓存，用`Debounce`和`SwitchToLatest`的组合，比手写`Task`管理更简洁。

与遗留RxSwift代码混编。大型项目迁移成本高，Combine作为官方方案，比继续依赖RxSwift风险更低。

需要精细控制背压（Backpressure）的场景。如实时音视频流处理，`Publisher`的`Buffer`策略比`AsyncStream`的缓冲机制更灵活。

但以上都是特定领域的窄缝。对于标准网络请求、数据库查询、UI状态绑定，Swift Concurrency的覆盖度已经足够。

开发者的实际选择困境

真正的问题不是技术优劣，是团队决策成本。

新项目无脑选`async/await`几乎没有争议。但存量项目呢？一个用Combine写了3万行业务代码的代码库，迁移的ROI（投资回报率）怎么算？

某中型团队的Tech Lead向我透露：他们2023年冻结了Combine的新增使用，老代码维持。结果比预期顺利——Swift Concurrency和Combine可以互操作，`Task`里能`await` `Publisher`的`values`属性，迁移可以按模块渐进。

苹果也提供了桥接工具。`AsyncAlgorithms`库里的`AsyncChannel`，设计目标就是衔接两种范式。

但桥接本身是技术债的信号。当官方同时维护两套异步抽象，开发者的认知负担不会减少，只是转移了。

一个观察：Swift 6的编译器对`async/await`的性能优化，已经让部分场景的速度反超Combine。苹果工程师在论坛确认，结构化并发的任务调度开销，在最新版本低于GCD（Grand Central Dispatch）派发的`Publisher`链。

Combine不会死。它和GCD、NSOperation一样，会成为基础设施层的遗留选项，被更高层的抽象包裹。但"你需要学Combine才能做iOS开发"的时代，确实过去了。

现在打开招聘软件，3年以上经验的iOS岗位描述里，"熟悉Swift Concurrency"的出现频率是"熟悉Combine"的7倍。市场投票比技术论证更直接。

你手头的项目还在用Combine吗？是历史包袱，还是确实有Combine才能解决的场景？