Dart - 完全解剖await/async原理
《解剖 async/await —— 状态机与控制流》摘要： 本文通过两章内容深入解析Dart异步编程机制。第一章揭示编译器如何将async/await代码剪切成多个"续体"(Continuation)，通过脱糖展示await本质是立即返回并将后续代码转为回调。第二章展示编译器如何生成状态机类，将局部变量提升为成员变量，使用状态指针和switch-case结构管理代码碎片执行顺
准备好了吗？我们要把你习以为常的代码撕碎，看看它的内脏长什么样。
第一章：拆解 —— 编译器的“剪刀”
作为 Dart 开发者，我们每天都在写 async 和 await。它们就像空气一样自然，以至于我们常常忘记了它们的存在。
看下面这段代码，它优雅、线性，符合人类的直觉：
Future<void> makeCoffee() async {
print("1. 开始烧水...");
await boilWater(); // 耗时操作
print("2. 放入咖啡粉...");
await brew(); // 耗时操作
print("3. 咖啡做好了，开喝！");
}
我们要问一个触及灵魂的问题：
Dart 是单线程的。既然代码在 await boilWater() 这一行“停”住了，为什么你的 App 界面没有卡死？为什么在这个等待期间，用户点击按钮还有反应？
如果你回答“因为它在后台线程跑”，那就大错特错了（除非你用了 Isolate）。这段代码自始至终都跑在 UI 线程（Main Isolate） 上。
真相只有一个：虚拟机根本就没看到上面那段代码。 它是编译器为你编织的一个完美的谎言。
1.1 编译器的“剪刀” (The Compiler’s Scissors)
在编译阶段，Dart 编译器手里拿着一把“隐形的剪刀”。它会扫描你的 async 函数，寻找每一个 await 关键字。
await 对你来说是“等待”，但对编译器来说，它是一个“切分点” (Split Point)。
每遇到一个 await，编译器就会咔嚓剪一刀，把你原本完整的函数切成好几段“碎片”。
1.2 还原真相：降维打击 (Desugaring)
如果我们要把这种“碎片化”还原成 Dart 1.0 时代的代码，它长什么样？
所谓的 await，本质上就是把**“剪刀后面的所有代码”打包，注册为“剪刀前面那个 Future”**的回调。
让我们手动进行一次 Desugaring (脱糖)：
// 编译器眼里的 makeCoffee（伪代码）
Future<void> makeCoffee() {
// --- 碎片 1：同步执行部分 ---
print("1. 开始烧水...");
// 遇到第一个 await，函数其实在这里就 RETURN 了！
// 它把剩下的代码打包成了 callback
return boilWater().then((_) {
// --- 碎片 2：第一个回调 ---
print("2. 放入咖啡粉...");
return brew().then((_) {
// --- 碎片 3：第二个回调 ---
print("3. 咖啡做好了，开喝！");
return null;
});
});
}
看清了吗？
- 没有暂停：函数并没有神奇地停在中间，而是通过
.then注册完回调后，立刻返回（Return）了。 - 回调地狱：
async/await并没有消除回调地狱，它只是把它藏起来了。
1.3 控制流的“蹦床”
理解了“立即返回”，你就能理解为什么 UI 不会卡死了。
因为 makeCoffee 在执行到第一个 await 时，实际上是把控制权**交还（Yield）**给了 Event Loop。主线程就像一个只有一条跑道的操场，makeCoffee 跑了一半离场了，Event Loop 赶紧安排“UI 绘制任务”上跑道去跑。
1.4 理论升华：CPS (Continuation-Passing Style)
现在，请把目光聚焦在那些被剪下来的“后续代码碎片”上：
// 这一坨代码，就是等待 boilWater 完成后要执行的东西
(_) {
print("2. 放入咖啡粉...");
return brew().then(...);
}
在计算机科学中，这种**“在特定时刻之后剩余的所有计算逻辑”**，有一个非常优雅的学名——Continuation (续体)，意为“待续的部分”。
而这种**“不直接返回结果，而是把‘接下来要做的事’打包成一个函数传给下一步”**的编程风格，就叫做 CPS (Continuation-Passing Style，续体传递风格)。
总结一下第一章的核心结论：
Dart 编译器是一个勤劳的翻译官。它将你写的 async/await 代码（Direct Style），悄悄翻译成了 CPS 风格的代码。
await不是暂停，是 Return。await后面的代码，是 Continuation。
但是，如果一个函数里有 10 个 await，就会切出 11 个碎片。如果用嵌套的 .then 来管理，代码会变成无法维护的“金字塔”。
编译器是如何优雅地管理这一地碎片的？它没有用 .then，而是生成了一个复杂的类。
这就引出了下一章的主角——状态机 (State Machine)。
这是 《解剖 async/await —— 状态机与控制流》 系列的第二章。
在第一章中，我们见识了编译器的“剪刀”，它把我们线性的代码切成了一地碎片（Continuations）。现在面临的问题是：怎么把这些碎片重新粘合起来，让它们能按正确的顺序执行，并且还能记住之前的状态？
欢迎来到编译器的核心魔术现场。这一章，我们将见证 状态机 (State Machine) 的诞生。
第二章：重组 —— 状态机的诞生
如果说第一章是“破”，这一章就是“立”。我们要揭示隐藏在优雅的 async 关键字背后的那个庞大而精巧的数据结构。
2.1 核心冲突：丢失的上下文 (The Vanishing Context)
让我们回到第一章的结论：当代码执行到 await 时，当前的函数实际上是执行了 Return 操作，把控制权交还给了事件循环。
在计算机底层原理中，“函数返回”意味着一个严重的后果：该函数的栈帧 (Stack Frame) 被销毁了。
保存在栈帧里的东西——所有的局部变量、临时参数——都会灰飞烟灭。
来看看我们稍微复杂一点的 makeCoffee：
Future<void> makeCoffee(String type) async {
// 局部变量，住在栈上
int waterAmount = type == "Espresso" ? 50 : 200;
print("准备制作 $type，需要水量: $waterAmount ml");
await boilWater(waterAmount);
// 恢复执行时，type 和 waterAmount 必须从堆里找回来
print("放入咖啡粉，开始萃取 $type...");
await brew();
print("3. 咖啡做好了，开喝！");
}
冲突点：异步执行需要跨越时间。在等待期间，我们必须找个地方把这些局部变量“存”起来，而且这个地方不能是“用完即弃”的栈，必须是能长期存储的 堆 (Heap)。
2.2 惊人转变：从函数到对象 (From Function to Object)
编译器是如何解决“上下文保存”问题的？答案极具想象力。
揭秘时刻：每一个被你标记为 async 的函数，在编译后，实际上都变成了一个自定义的 类 (Class)。
Dart 编译器会为你悄悄生成一个类，通常命名类似于 _MakeCoffeeStateMachine。
“变量搬家”工程
编译器会进行一次大规模的“搬家”行动：它会扫描你的异步函数，把所有需要在 await 之后继续使用的局部变量，统统提升为这个生成类的成员变量 (Fields)。
这样一来，这些变量就从“暂住的栈”搬到了“永居的堆”（因为对象是分配在堆上的）。只要这个状态机对象不死，这些变量就一直存在。
此外，这个类还需要一个最重要的核心变量：状态指针 (_state)。它是一个整数，用来记住当前代码执行到了第几个碎片。
2.3 核心结构：巨大的 Switch-Case
现在，变量有了安身之所，那执行逻辑呢？那些代码碎片怎么组织？
生成的状态机类中，会有一个核心方法（我们姑且叫它 moveNext()）。这个方法的内部，就是一个巨大的 switch-case 结构，用来分发我们在第一章切出来的那些代码碎片。
让我们来看看编译器视角下的代码结构图：
2.4 拼图完成：伪代码全貌
结合变量搬家和 Switch 结构，我们可以写出编译器生成的那个“幕后黑手”的伪代码了：
// 编译器生成的幕后类
class _MakeCoffeeStateMachine {
// --- 1. 成员变量 (搬家后的局部变量) ---
int _state = 0; // 状态指针，初始为 0
String type; // 以前是参数
int waterAmount; // 以前是局部变量
Completer<void> _completer = Completer(); // 用来控制最终返回的那个 Future
// 构造函数接收初始参数
_MakeCoffeeStateMachine(this.type);
// --- 2. 核心方法：推动状态机运转 ---
void moveNext() {
try {
switch (_state) {
case 0: // --- 碎片 1：立即执行部分 ---
waterAmount = type == "Espresso" ? 50 : 200;
print("准备制作 $type，需要水量: $waterAmount ml");
// 关键：修改状态，准备去下一个 case
_state = 1;
// 注册回调，然后立即 RETURN (挂起)
// 注意：这里把 `this.moveNext` 注册为了回调！
boilWater(waterAmount).then((_) => this.moveNext());
return;
case 1: // --- 碎片 2：第一个回调恢复 ---
// 此时 waterAmount 和 type 依然从成员变量里读取，数据还在！
print("放入咖啡粉，开始萃取 $type...");
_state = 2;
brew().then((_) => this.moveNext());
return; // 再次挂起
case 2: // --- 碎片 3：最后的部分 ---
print("3. 咖啡做好了，开喝！");
// 任务全部完成，通知外界
_completer.complete();
return;
}
} catch (e) {
// 处理异常（第四章细讲）
_completer.completeError(e);
}
}
// 对外暴露的 Future
Future<void> get future => _completer.future;
}
总结一下第二章：
所谓“异步函数”，在骨子里是一个对象。
编译器通过把函数转换成类，把局部变量提升为成员变量，成功地在堆上保存了执行上下文。而那个巨大的 switch-case 结构，就是管理代码碎片执行顺序的调度器。
现在，结构已经搭好了，静态的模型已经建立。
那么，这个机器是怎么动起来的？是谁在调用 moveNext()？控制权是如何在状态机和事件循环之间倒手的？
下一章，我们将让这个状态机运转起来，看看它的动态流转过程。
这是 《解剖 async/await —— 状态机与控制流》 系列的第三章。
在前两章里，我们像法医一样，把一个活生生的异步函数“解剖”成了碎片（CPS），然后又看着编译器像弗兰肯斯坦一样，把这些碎片缝合成了一个怪异的物体——状态机对象 (State Machine Object)。
此刻，这个对象静静地躺在堆内存里，拥有了结构（Switch-Case）和记忆（成员变量），但它还没有生命。
这一章，我们将接通电源。我们要亲眼目睹控制权是如何在状态机和事件循环之间像打乒乓球一样来回传递的。这才是“非阻塞”的终极奥义。
第三章：流转 —— 暂停与恢复的艺术
我们常说 await 让函数“暂停”和“恢复”了。这听起来很神奇，仿佛时间静止了一样。
但学完前两章你已经知道，底层的世界里没有魔法，只有冷冰冰的 Return (函数返回) 和 Callback (回调)。
所谓的“暂停与恢复”，本质上是一场精心编排的**“接力赛”**。
3.1 启动：第一推力 (The Ignition)
一切始于你在一行普通的同步代码中调用了这个异步函数：
void main() {
print("主程序开始");
// 这一行，就是点火时刻
Future<void> coffeeFuture = makeCoffee("Espresso");
print("主程序继续做其他事...");
// ...
}
当你执行 makeCoffee("Espresso") 时，机器内部发生了什么？
- 创建实例：在堆上 new 了一个
_MakeCoffeeStateMachine的实例对象。
class _MakeCoffeeStateMachine {
// --- 1. 成员变量 (搬家后的局部变量) ---
int _state = 0; // 状态指针，初始为 0
String type; //参数
int waterAmount; /是局部变量
Completer<void> _completer = Completer(); // 用来控制最终返回的那个 Future
// 构造函数接收初始参数
_MakeCoffeeStateMachine(this.type);
// --- 2. 核心方法：推动状态机运转 ---
void moveNext() {
//...省略
}
- 保存参数：把字符串
"Espresso"存入对象的成员变量this.type。
class _MakeCoffeeStateMachine {
// --- 1. 成员变量 (搬家后的局部变量) ---
int _state = 0; // 状态指针，初始为 0
String type; //参数-------------------------------------->保存参数
int waterAmount; /是局部变量
Completer<void> _completer = Completer(); // 用来控制最终返回的那个 Future
// 构造函数接收初始参数
_MakeCoffeeStateMachine(this.type);
// --- 2. 核心方法：推动状态机运转 ---
void moveNext() {
//...省略
}
- 手动点火（关键！）：编译器会自动插入一行代码，手动调用一次这个对象的
moveNext()方法。
这是第一张多米诺骨牌。
此时，_state 是 0。switch 跳到 case 0，开始同步执行第一段代码：计算水量，打印 “开始烧水…”。
3.2 交权：关键的“握手” (The Handover)
代码一路狂奔，直到撞上了第一个墙壁：await boilWater()。
这是整个机制中最精彩的瞬间。状态机不能在这里干等，否则主线程就卡死了。它必须把控制权交出去。
在伪代码层面，这一刻发生了两个关键动作：
case 0:
// ... 执行同步代码 ...
// 动作 A：记住下一步该去哪
_state = 1;
// 动作 B：关键握手！
// 状态机对自己说：“boilWater，等你完事了，记得叫我一声。”
// “我是谁？我就是这个 moveNext 方法本身！”
boilWater().then((_) => this.moveNext());
// 动作 C：立即撤退！控制权交还给 Event Loop
return;
看懂了吗？状态机并没有“暂停”，它只是把自己（moveNext 方法）注册成了回调，然后光荣退场了（Return）。
此时，主线程空闲下来，Event Loop 愉快地接过控制权，去处理界面刷新、响应按钮点击等其他任务。
几秒钟后，烧水任务完成了。
- 系统底层发出信号。
- Event Loop 查看之前的记录，发现这个任务完成时需要调用一个回调。
- Event Loop 执行回调，也就是再次调用了状态机的
moveNext()方法。
这次进来时，_state 已经是 1 了。
switch 精准地跳过了 case 0，直接落入了 case 1。这就仿佛代码从上次离开的地方“恢复”了一样！
- 它从成员变量里读取之前存下的
type（上下文恢复了！）。 - 打印 “开始萃取…”。
- 遇到
await brew()。 - 历史重演：
_state变成 2，注册this.moveNext为回调，然后再次 Return，把控制权像打乒乓球一样又打回给了 Event Loop。
这就是“非阻塞”的真相：不是一条线程在死等，而是控制权在状态机和事件循环之间高频、有序地切换。
3.4 终局：Completer 的使命
终于，最后一步 brew() 也完成了。Event Loop 第三次调用 moveNext()。
这一次，_state 是 2，进入最后一个 case。
case 2:
print("3. 咖啡做好了，开喝！");
// 游戏结束。
// 那个在最外面等待 makeCoffee() 的人，还在痴痴地等呢。
// 是时候通知他了！
_completer.complete();
return;
还记得我们在第二章状态机里埋下的那个 Completer 成员变量吗？它是连接状态机内部世界和外部调用者的桥梁。
调用 _completer.complete() 的瞬间，外部那个 coffeeFuture 终于变成了 “Completed” 状态。外部跟着的 .then() 或 await 后面的代码得以继续执行。
至此，整个异步任务圆满结束，状态机对象完成了它的历史使命，等待被垃圾回收 (GC)。
总结一下第三章的顿悟时刻：
你以为的“恢复执行”，并不是虚拟机真的有一个“时光倒流”按钮回到过去。
真相是：函数被重新调用了一次 (Re-entry)。
只是因为这个函数变成了一个对象，并且它肚子里有一个 _state 变量记住了“上次读到哪一页了”，所以它每次都能精准地接着往下读。
现在，我们已经彻底搞清了正常流程。但是，如果烧水的时候炉子炸了怎么办？
下一章，我们将揭开最后一个谜团：在这一堆支离破碎的回调和状态跳转中，Dart 是如何实现跨越时空的异常捕获 (try-catch) 的？
好的，这个要求非常合理。只有看到“尸体解剖”后的完整代码，才能真正理解异常是如何流转的。
我们将按照**“源代码 -> 反编译代码 -> 流程逐帧解析 -> 总结”**的顺序来完成这一章的核心部分。
第四章：异常 —— 跨越时空的救赎
4.1 核心：反编译全貌 (The Decompiled Reality)
首先，这是我们写的源代码，简单直接：
// 源代码
Future<void> makeCoffee() async {
try {
// [State 0]
await boilWater();
// [State 1]
print("水开了");
} catch (e) {
// [State 2]
print("炸炉了: $e");
}
}
下面是编译器生成的状态机伪代码。请仔细观察 moveNext 方法中的 try-catch 结构，以及底部的 _handleException（模拟异常跳转表）。
// 编译器生成的幕后类（反编译视角）
class _MakeCoffeeStateMachine {
// --- 1. 成员变量 ---
int _state = 0; // 状态指针
Object? _pendingError; // 暂存异步带回来的错误
Completer<void> _completer = Completer();
// --- 2. 核心驱动方法 ---
void moveNext() {
while (true) { // 一个循环，用来支持 state 的连续跳转
try {
// [关键点 A]: 如果有上次异步任务留下的错误，先在这里抛出来！
// 这样就能被下面的 catch 捕获，从而进入路由逻辑。
if (_pendingError != null) {
var error = _pendingError;
_pendingError = null;
throw error;
}
// --- 核心 switch 分发 ---
switch (_state) {
case 0:
// --- 对应源代码：try { await boilWater(); } ---
_state = 1; // 设定好：如果成功，下次去 case 1
// 调用异步任务
var future = boilWater();
// [关键点 B]: 注册回调
// 无论成功还是失败，都把结果存一下，然后再次调用 moveNext
future.then(
(value) {
// 成功：直接回调
this.moveNext();
},
onError: (error) {
// 失败：存下错误，标记为待处理，然后回调
this._pendingError = error;
this.moveNext();
}
);
return; // 挂起！交出控制权
case 1:
// --- 对应源代码：print("水开了"); ---
print("水开了");
// 任务正常结束
_completer.complete();
return;
case 2:
// --- 对应源代码：catch (e) { ... } ---
// 这里能拿到刚才抛出的异常
print("炸炉了: ${_currentException}");
_completer.complete();
return;
}
} catch (e) {
// --- 3. 全局救生网 ---
// [关键点 C]: 一旦发生异常，查表！
_handleException(e);
}
}
}
// --- 4. 异常跳转表 (Exception Table) ---
void _handleException(Object exception) {
// 编译器在这里硬编码了路由逻辑：
// "如果当前是在 State 0 或 1 炸的，就去 State 2 (catch块)"
if (_state == 0 || _state == 1) {
_state = 2; // <--- 强制变轨！
_currentException = exception; // 把错误对象交给 catch 块
// 注意：这里没有 return，循环会继续，马上执行 case 2
} else {
// 如果 State 2 (catch块) 里也炸了，或者没写 try-catch
// 那就彻底没救了，通知外界 Future 失败
_completer.completeError(exception);
}
}
Object? _currentException; // 临时存一下给 catch 块用的变量
}
4.2 慢动作回放：异常流转七步曲
现在，我们假设 boilWater() 在 3 秒后抛出了一个 “Boom!” 异常。让我们看看上面的代码是如何一步步执行的。
第一阶段：埋雷
- State 0 启动:
moveNext()首次运行，进入case 0。 - 设定路线: 将
_state设为 1（默认成功路径）。 - 挂起: 调用
boilWater()，注册了回调，状态机return。主线程去干别的事了。
第二阶段：引爆
- 异步回调: 3 秒后，
boilWater失败。Future 触发onError回调。 - 存雷: 回调函数执行
this._pendingError = "Boom!"。 - 重启: 回调函数再次调用
this.moveNext()。
第三阶段：排雷与变轨
- Re-entry (重入):
moveNext()再次开始执行。 - 抛雷 [关键点 A]: 代码一进来检查
if (_pendingError != null)，发现有雷！于是throw "Boom!"。 - 被捕获 [关键点 C]: 这个
throw瞬间被外层的catch (e)捕获。switch根本没机会执行。 - 查表: 进入
_handleException(e)。
- 检查：刚才我本来打算去哪？(
_state此时是 1)。 - 规则：State 0 和 1 都在
try块保护范围内。 - 动作：把
_state强行改为 2 (即用户的 catch 块)。
第四阶段：软着陆
- Loop 继续: 因为
_handleException里没有 return，while(true)循环继续转动。 - 进入 Case 2: 这一次，
switch(_state)看到的是 2。 - 执行救灾: 执行
print("炸炉了: Boom!")。 - 完成:
_completer.complete()。
4.3 总结
通过这次反编译和流转分析，我们可以得出关于 Dart 异步异常处理的三个终极结论：
- 没有真正的“异步捕获”：
所谓的跨越时空捕获，其实是**“异步传递 + 同步抛出”**。错误先被存在变量里 (_pendingError)，等状态机再次运行时，在同步环境里被主动throw出来，从而利用了同步的try-catch机制。 - State Machine 是个“作弊者”：
它不仅记住了代码执行到哪一行（_state），还随身带着一张地图（Exception Table）。一旦出事，它知道该把代码强行跳转到哪里。 - try-catch 只是路由规则：
在异步代码中，try-catch不再是运行时的栈保护结构，它在编译时就被硬编码成了状态机的状态跳转逻辑 (GOTO State X)。
这一章彻底揭开了 async/await 最晦涩的一面。现在，你已经完全理解了 Future 的所有底层机制。
下一章（终章），我们将跳出微观，去俯瞰 Dart 的并发全景图，看看 Future、Stream 和 Isolate 到底该怎么选。
这是 《解剖 async/await —— 状态机与控制流》 系列的最终章。
在前四章，我们将显微镜推到了极致，看清了每一颗螺丝钉。现在，是时候收起显微镜，拿出望远镜，站在上帝视角来审视这一切了。
懂得原理，不仅仅是为了炫技，更是为了在实战中做出更聪明的决策。
第五章：总结
5.1 原理反哺实战：给老司机的三条建议
既然你已经知道了 async 函数背后是一个状态机，那么在写代码时，你的直觉应该发生改变。以下是三条基于底层原理的高级建议：
1. 警惕“蹦床效应” (The Trampoline Cost)
- 原理回顾：每次
await，本质上都是一次return（挂起）和一次基于 Event Loop 的回调（恢复）。这就像在蹦床上跳跃，虽然不阻塞线程，但“起跳”和“落地”是有调度成本的。 - 实战建议：不要滥用
await。
如果任务 B 不依赖任务 A 的结果，千万不要串行地写await A(); await B();。这会导致状态机频繁地挂起和恢复，浪费调度资源。
**请使用Future.wait([A(), B()])**。这能让两个任务并行跑在 Event Loop 上，状态机只需挂起一次，等待它们全部回来。
2. 关注“堆内存膨胀” (Heap Bloat)
- 原理回顾：
async函数里的局部变量，会被“搬家”到堆上的状态机对象里成为成员变量。 - 实战建议：避免编写巨型的
async函数。
如果你写了一个几百行的async函数，里面定义了几十个大对象（List, Map 等）作为临时变量。哪怕你只在第一行用了它们，它们也可能会一直赖在状态机对象里，直到整个函数结束才能被 GC（垃圾回收）。
拆分函数，让小的状态机尽快销毁，释放内存。
3. 看懂“骗人”的堆栈 (The Lying Stack Trace)
- 原理回顾：异常流转是“存雷”再“抛雷”的过程，真实的物理调用栈早断了。
- 实战建议：调整心态。
当你看到异步报错的 Stack Trace 时，不要困惑为什么有些帧看起来很奇怪（充满了_rootRun,microtaskLoop等系统底层方法）。你现在知道，这是 Dart VM 尽力为你“伪造”的一个逻辑调用栈。理解了这一点，调试异步 Bug 时你会更加从容。
5.2 重绘地图：三驾马车的最终定论
回到我们最开始的问题：Future、Stream、Isolate 到底怎么选？站在状态机的视角，界限非常清晰：
- Future (状态机)：主线程上的时间管理大师。
- 本质是切分。它把一个长任务切成碎片，利用等待时间让出 CPU。
- 适用：网络请求、文件读写、数据库操作。
- Isolate (真线程)：主线程的替身使者。
- 如果状态机里某个
case的同步代码（比如解析 10MB 的 JSON，或图像处理）执行时间太长（超过 16ms），moveNext就会卡住，导致主线程掉帧。 - 这时候，必须把这个计算任务扔给 Isolate。
- 适用：繁重的 CPU 计算。
- Stream (流水线)：可循环触发的状态机。
- Future 的状态机跑到终点就结束了（Completer 完成）。
- Stream 可以理解为一个不立即销毁的状态机。它可以被多次唤醒，源源不断地吐出数据。
5.3 核心思想总结：同步的幻象，异步的真相
最后，为了回应你对 async/await 本质的好奇，我们用一段话来总结这套语法的哲学内核：
async/await 本质上是一场精彩的编译器魔术，旨在消除“人类思维”与“机器执行”之间的鸿沟。
- 人类的思维是线性的：我们习惯顺序做事（烧水 -> 倒粉 -> 喝咖啡），这种风格被称为 Direct Style（直接风格）。
- 机器的高效是碎片的：为了不阻塞线程，代码必须写成 CPS（Continuation-Passing Style，续体传递风格），即“做完这步，回调下一步”。
Dart 编译器利用 状态机 (State Machine) 作为桥梁，在编译阶段将我们写给人看的线性代码，切割并重组为机器喜欢的CPS 碎片。
它让代码在形式上保持了同步逻辑的连贯性与可读性，却在执行上拥有了异步逻辑的非阻塞与高并发。这就是 async/await 最大的魅力——写的是同步的诗，跑的是异步的魂。
有“AI”的1024 = 2048，欢迎大家加入2048 AI社区
更多推荐
0
0- 0
已为社区贡献2条内容
所有评论(0)