Swift 并发里最容易被忽略的性能坑：你以为是并发，其实是串行

大家好，我是展菲，目前在上市企业从事人工智能项目研发管理工作，平时热衷于分享各种编程领域的软硬技能知识以及前沿技术，包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。

图书作者：《ESP32-C3 物联网工程开发实战》
图书作者：《SwiftUI 入门，进阶与实战》
超级个体：COC上海社区主理人
特约讲师：大学讲师，谷歌亚马逊分享嘉宾
科技博主：华为HDE/HDG

我的博客内容涵盖广泛，主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告，同时也会提供产品优缺点分析、横向对比，并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。

展菲：您的前沿技术领航员
👋 大家好，我是展菲！
📱 全网搜索“展菲”，即可纵览我在各大平台的知识足迹。
📣 公众号“Swift社区”，每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。
💬 微信端添加好友“fzhanfei”，与我直接交流，不管是项目瓶颈的求助，还是行业趋势的探讨，随时畅所欲言。
📅 最新动态：2025 年 3 月 17 日
快来加入技术社区，一起挖掘技术的无限潜能，携手迈向数字化新征程！

前言

如果你已经开始用 Swift Concurrency，大概率写过下面这种代码：

leta=awaitfetchA()letb=awaitfetchB()

写的时候很自然，用起来也没报错，但页面加载总感觉慢半拍。
后来你开始怀疑网络、怀疑后端、怀疑是不是埋点太多，唯独没怀疑过这两行代码。

但问题，往往就出在这里。

await 写多了，不一定是并发

先说一个容易被忽略的事实：

连续写的 await，默认是串行执行的。

也就是说，上面这段代码的真实执行顺序是：

1. 等fetchA()完成
2. 拿到结果
3. 再去等fetchB()完成
4. 两个都结束后，才继续往下走

哪怕fetchA和fetchB：

• 没有任何依赖关系
• 都是纯网络请求
• 理论上完全可以同时跑

Swift 也不会“帮你并发”。

一个非常真实的业务场景

想象一个常见页面：

• 请求用户信息
• 请求远程配置
• 两个接口互不影响
• 页面必须等两个接口都回来才能渲染

很多人第一反应就是这样写：

letuser=awaitfetchUserInfo()letconfig=awaitfetchRemoteConfig()

代码没问题，但体验上就是——慢。

那有没有办法，让它们真的同时跑？

Task Group：能解决，但有点重

如果你对 Swift 并发比较熟，可能会想到 Task Group：

letresult=awaitwithTaskGroup(of:Int.self){groupingroup.addTask{awaittaskA()}group.addTask{awaittaskB()}awaitgroup.waitForAll()returnawaitgroup.reduce(0,+)}

确实能并发，也很强大，但说实话：

• 为了等两个任务
• 写了一大坨模板代码
• 可读性开始下降

对于简单、固定数量的任务，这个成本有点高。

async let：Swift 并发里最好用的语法糖

Swift 其实早就考虑到了这种高频场景，于是给了一个非常舒服的写法：async let。

直接看代码：

asyncleta=taskA()asyncletb=taskB()letresult=awaita+bprint(result)

这几行代码，解决了刚才所有问题：

• taskA和taskB立即并发执行
• 不需要 Task Group
• 逻辑非常贴近业务语义

async let 到底“并发”在哪里？

很多人第一次看到async let会有点疑惑：

asyncleta=taskA()// 为什么这里没有 await？

原因其实很简单：

• async let的作用不是“取值”
• 而是“声明一个并发任务”

真正等待结果，是在你使用它的时候：

letresult=awaita+b

也就是说：

任务启动和等待是分离的

这正是性能优化的关键。

一个完整、可运行的 Demo

下面这段代码可以直接跑，能非常直观地看到效果：

functaskA()async->Int{try?awaitTask.sleep(nanoseconds:1_000_000_000)print("taskA finished")return10}functaskB()async->Int{try?awaitTask.sleep(nanoseconds:2_000_000_000)print("taskB finished")return20}Task{asyncleta=taskA()asyncletb=taskB()letresult=awaita+bprint("result:",result)}

执行结果类似：

taskA finished taskB finished result: 30

重点不是输出顺序，而是——
总耗时只有 2 秒，而不是 3 秒。

放到真实业务里，差距会被无限放大

首页加载

asyncletuser=fetchUserInfo()asyncletconfig=fetchRemoteConfig()letdata=awaitHomeData(user:user,config:config)

详情页组合接口

asyncletdetail=fetchDetail(id:id)asyncletstock=fetchStock(id:id)asyncletpromotion=fetchPromotion(id:id)letviewModel=awaitViewModel(detail:detail,stock:stock,promotion:promotion)

这种地方如果写成串行，
慢的不是一个接口，而是整个用户体验。

async let 什么时候不该用？

它也不是银弹，有明确边界：

• 任务数量是动态的 → 用 Task Group
• 需要复杂的失败回滚 → Task Group 更合适
• 生命周期要跨作用域 → async let 不行

一句话总结：

固定数量、互不依赖、结果要一起用 —— async let 是最优解。

总结

很多 Swift 并发性能问题，并不是你“不会并发”，
而是代码看起来像并发，实际却是串行。

async let这种语法，看似只是语法糖，
但在真实项目里，往往能直接决定一个页面是“秒开”还是“卡一下”。

如果你身边有人还在无意识地连写await，
把这篇文章丢给他，大概率能少踩一个坑。