大家好，我是展菲，目前在上市企业从事人工智能项目研发管理工作，平时热衷于分享各种编程领域的软硬技能知识以及前沿技术，包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。
图书作者：《ESP32-C3 物联网工程开发实战》
图书作者：《SwiftUI 入门，进阶与实战》
超级个体：COC上海社区主理人
特约讲师：大学讲师，谷歌亚马逊分享嘉宾
科技博主：华为HDE/HDG
我的博客内容涵盖广泛，主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告，同时也会提供产品优缺点分析、横向对比，并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。
展菲：您的前沿技术领航员
👋 大家好，我是展菲！
📱 全网搜索“展菲”，即可纵览我在各大平台的知识足迹。
📣 公众号“Swift社区”，每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。
💬 微信端添加好友“fzhanfei”，与我直接交流，不管是项目瓶颈的求助，还是行业趋势的探讨，随时畅所欲言。
📅 最新动态：2025 年 3 月 17 日
快来加入技术社区，一起挖掘技术的无限潜能，携手迈向数字化新征程！
文章目录
- 前言
- await 写多了，不一定是并发
- 一个非常真实的业务场景
- Task Group：能解决，但有点重
- async let：Swift 并发里最好用的语法糖
- async let 到底“并发”在哪里？
- 一个完整、可运行的 Demo
- 放到真实业务里，差距会被无限放大
- 首页加载
- 详情页组合接口
- async let 什么时候不该用？
- 总结
前言
如果你已经开始用 Swift Concurrency，大概率写过下面这种代码：
leta=awaitfetchA()letb=awaitfetchB()写的时候很自然，用起来也没报错，但页面加载总感觉慢半拍。
后来你开始怀疑网络、怀疑后端、怀疑是不是埋点太多，唯独没怀疑过这两行代码。
但问题，往往就出在这里。
await 写多了，不一定是并发
先说一个容易被忽略的事实：
连续写的 await，默认是串行执行的。
也就是说，上面这段代码的真实执行顺序是：
- 等
fetchA()完成 - 拿到结果
- 再去等
fetchB()完成 - 两个都结束后，才继续往下走
哪怕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，
把这篇文章丢给他，大概率能少踩一个坑。
)
