历史包袱：海量第三方 SDK 仍是回调形态 痛点： 嵌套地狱（Callback Pyramid） 错误处理分散 难以取消 官方桥接器：withCheckedThrowingContinuation 核

Actor 是什么？ Actor 是引用类型（与 class 类似），但自带隔离域： 任意时刻只允许一个任务进入 Actor 内部 外部调用必须加 await，自动排队 编译器保证无数据竞争，无需手动

最理想的情况下，系统、第三方框架当中使用回调的 API 都最好在一夜之间改成 async 函数，显然这不太现实。

在真实的业务场景中，我们难免会创建很多 Task 实例来执行不同的异步任务，但这些任务之间往往都是存在关联的。

结构化并发： 一种组织并发任务的编程范式，强调任务之间的明确父子关系和生命周期管理，任务形成明确的父子关系树，父任务取消会自动传播到所有子任务， 作用域结束时也会自动等待所有子任务完成 非结构化并发：

思维导图（先保存，再阅读） 为什么分“结构化”与“非结构化” 维度 Structured Unstructured 能否成为子任务 ✅ ❌（只能是根） 能否成为父任务 ✅ ✅（再开 structure

背景：为什么突然冒出 @concurrent？ Swift 6.2 引入了两项默认行为变化： Main Actor 默认隔离(UI相关的Target或package) 未显式标注隔离的代码自动视为 @

背景：Swift 6 的“并发安全”红线 在 Swift 5 时代，开启 Strict Concurrency 后，以下代码会报错： Swift5时 Task的初始化方法定义 原因：Task 的 op

一、为什么单例在 Swift 6 突然“不香了” 旧认知 Swift 6 新现实 static let shared = XXX()随手一写 编译器直接甩出两行血红诊断：1. 非隔离的全局可变状态（n