1. 先搞清楚Dart的事件循环Future才能学得明白1.1 同步代码的阻塞问题在我自己的学习笔记序列里前面大部分篇幅都在记语法、类、集合这些同步世界的东西到了Future这一篇明显感觉Dart开始跟别的语言不太一样了。刚接触异步的人最容易产生的一个错误直觉是Future是不是像其它语言的线程一样在后台并行跑一个任务还真不是。先看个最简单的例子。假设你要从本地存储里读一个大文件再对内容做解析处理void main() { final data loadBigFile(); // 假设要花500ms final result parseData(data); // 再花300ms print(result); }这段代码在Dart里是串行执行的如果遇到网络请求、文件IO这种耗时的操作后面所有代码都得排队等着。在移动端上的体验就是界面直接卡住用户划不动屏幕。其它语言处理这个问题通常会引入线程或线程池把耗时任务丢到别的线程去跑。但Dart不一样Dart默认跑在一个单线程的isolate里它没有像Java那种共享内存的多线程模型处理异步用的是事件循环 Future这套组合拳。理解这件事的意义在于你在Dart里不存在加一把锁保护共享变量这种思路所有并发问题的解法其实都围绕事件什么时候被安排、按什么顺序被执行展开。把隔离区、消息传递这些概念往后放一放先搞定事件循环后面学Stream、学Isolate都不会太吃力。1.2 事件循环微任务队列与事件队列理解Dart异步只需要抓住两个队列微任务队列microtask queue和事件队列event queue。Dart的事件循环会先把当前同步代码执行完然后反复做一件事先把微任务队列清空再从事件队列里取一个事件处理处理完继续清空微任务队列如此循环往复。void main() { print(A); Future(() print(B)); // 事件队列 scheduleMicrotask(() print(C)); // 微任务队列 Future.microtask(() print(D)); // 微任务队列 print(E); }猜一下输出顺序。实际输出是A → E → C → D → B。同步代码A和E先跑完C和D因为挂在微任务队列里所以它们会在事件队列里的B之前执行。这个顺序在我第一次跑的时候确实吓了一跳因为它直接决定了你写Future时的行为预期——不是后写的先跑或者先写的先跑而是看任务落在哪个队列里。队列放入方式执行时机典型用途微任务队列scheduleMicrotask、Future.microtask、async函数内部恢复当前同步代码结束后、事件队列之前需要尽早执行的轻量任务事件队列Future()构造器、Future.delayed、计时器、IO回调微任务清空之后耗时任务、外部事件为什么要设计两个队列我的理解是微任务队列用来保证当前逻辑的收尾工作能尽快完成比如一个Future链上的下一个then事件队列则留给真正的耗时任务和外部事件。两者严格分优先级Dart才能让异步代码既高效又可控。1.3 Future不是线程它是一个快递单搞清楚了队列再看Future就清晰了。我把Future理解成一张快递单你现在没有拿到实际包裹结果但你先拿到了这张单子单子上的物流状态将来会变成已送达也可能变成配送失败。Dart里这张单子有三种状态未完成、已完成带值、已完成带错误。值得强调的是Future本身并不做任何耗时计算它只是把一段计算安排到某个队列里并承诺将来给你结果。真正干活的是事件循环。这也是很多人学Future时最大的误区以为用了Future就异步了其实你只是把任务交了出去计算到底什么时候执行、按什么顺序执行仍然由事件循环说了算。想清楚这一点后面所有链式调用、错误处理的行为才能解释得通。打个比方你去餐厅吃饭点完菜拿到一张小票小票本身不能让你吃饱但它代表厨房会给你做。Future就是这张小票厨房事件循环什么时候炒你的菜取决于排在你前面的订单有多少。2. 创建Future的五个入口各管一摊2.1 Future()构造器把计算丢给事件队列最直白的创建方式就是Future(...)传入一个会在将来执行的函数FutureString fetchInfo() { return Future(() { // 这中间可以做耗时的事情 return 模拟拿到的数据; }); }Future(() {...})会把函数体作为一个事件丢进事件队列也就是说它不会立即运行至少要等当前同步代码和微任务都处理完。这里有个容易踩的认知差函数体里的代码是将来执行的不是马上执行的。如果你在构造函数里需要立刻捕获同步异常那就得换Future.sync了这一点在讲错误处理时会专门展开。2.2 Future.delayed延时任务的正确姿势定时延时是使用频率特别高的场景比如轮询、防抖、或者模拟网络延迟写法是Future.delayed(Duration(seconds: 2), () { return 两秒后返回; });第一个参数是等待时间第二个参数是要执行的回调。如果只想延时但不需要返回值也可以省略第二个参数直接await Future.delayed(Duration(seconds: 1))。这里有个容易被忽略的细节Future.delayed不是精确计时。如果事件循环当前很忙回调实际执行时间可能比指定时间更晚。它保证的是至少等这么久不是恰好等这么久。所以别拿它做需要严格秒级同步的逻辑比如动画帧同步或者精密倒计时那会需要更底层的时钟方案。2.3 Future.value / Future.error / Future.sync / Future.microtask剩下几种创建方式各有各的用处我在实际代码里几乎天天遇到。Future.value(x)立刻创建一个已完成且值为x的Future。典型场景是给函数一个统一的Future返回类型比如某个接口在缓存命中时直接返回缓存值FutureCacheData getData() { final hit cache.read(); if (hit ! null) { return Future.value(hit); // 已经是结果了直接包装 } return fetchFromNetwork(); }Future.error(e)立刻创建一个已完成但带错误的Future适合在异步接口里主动上报失败比如参数校验不过FutureUser login(String name, String pwd) { if (name.isEmpty || pwd.isEmpty) { return Future.error(ArgumentError(参数不能为空)); } return doLogin(name, pwd); }Future.sync(fn)立即同步执行fn然后把结果包装成Future。它和Future(...)最大的区别在于执行时机sync在调用那一刻就跑函数体而不是排队。这个特性后面会讲到它能把同步异常正确包装成Future的错误。Future.microtask(fn)把fn丢进微任务队列比事件队列先执行。适合虽然异步、但要尽快跑的轻量任务。快速对比一下final a Future.value(42); // 已完成值42 final b Future.error(出错了); // 已完成带错误 final c Future.sync(() { // 函数体立刻执行 return computeSomething(); }); final d Future.microtask(() { // 进微任务队列尽快执行 return microtask; });2.4 创建方式选型对照表我把这几种方式整理成一个选型表日常写代码对着选就行创建方式执行时机同步异常捕获适用场景Future(fn)事件队列异步捕获真正的耗时任务Future.delayed定时事件异步捕获延时、模拟网络Future.value立即完成不适用默认值、统一返回类型Future.error立即失败不适用主动报错Future.sync(fn)立即执行同步捕获纯计算但想统一异步接口Future.microtask微任务队列异步捕获轻量、尽早执行的任务这里要特别提醒一个知识点的关联在一个async函数体里直接throw这个错误会被自动包装成Future.error返回给调用方。所以你写同步代码抛异常时外面用try/catch包住await就能捕获不会直接把进程带崩。这个机制看起来简单但它依赖的正是async函数最终返回Future这条规则。3. then链与async/await两种消费方式一种执行秩序3.1 then/catchError/whenComplete的执行链路拿到Future之后最基础的消费方式是.then()Future.value(20) .then((value) value * 2) .then((value) value 1) .then((value) print(value)); // 输出41每个then都在上一个Future完成后执行前一个回调的返回值会成为下一个回调的入参。整条链是顺序执行的并不会并行。值得记住的是then里的回调本身是作为一个微任务被调度的所以每经过一个then代码会回到事件循环的微任务队列把排在它前面的微任务处理完再继续往下走。链上还有两个常用的方法catchError捕获前面任意一环抛出的错误。whenComplete不管成功还是失败都会执行类似其它语言的finally。fetchData() .then((data) render(data)) .catchError((e) print(出错了: $e)) .whenComplete(() loading false);这里有个细节很多人以为whenComplete一定要写在最后其实它写在中间也可以只是执行时机同样是前面的Future链处理完以后。这个方法的定位就是收尾不管是失败还是成功该释放的资源、该恢复的状态都放这里。3.2 async/await语法糖背后的then相比链式调用async/await是我日常写的主力写法因为它把嵌套回调拉平了Futurevoid loadPage() async { try { final user await fetchUser(); final posts await fetchPosts(user.id); show(posts); } catch (e) { showError(e); } finally { loading false; } }从原理上讲await就是then的语法糖编译器会把等待结果再继续的逻辑转成一个回调挂到then上。所以你用链式写法还是await写法最终的执行秩序是同一套事件循环规则不存在await更快这种说法。但await有个实际好处错误处理用的是熟悉的try/catch/finally不用时刻惦记着catchError的返回值类型问题。我在学习过程中专门测试过一个点await之后如果抛错catch能捕获到但如果根本没加try/catch错误会变成一个未处理的异步错误直接交给Zone处理。在Flutter里通常表现为控制台打印一大段未捕获异常或者调试模式下直接红屏。这个行为跟JavaScript里的unhandled rejection很像排查起来往往比同步异常更费劲因为出错现场已经过去了。3.3 链式写法与await混用时的类型陷阱如果你把链式写法跟await混着用要小心catchError的返回类型。看一个实际项目里很常见的坑Futureint fetch() async { throw Exception(网络错误); } final result await fetch() .then((v) v 1) .catchError((e) 重试); // 类型从int变成了String print(result); // result实际是String 重试这个例子编译可能不报错但catchError返回的重试会直接顶替掉整个链路的值下游如果还当int处理就会出问题。处理办法是让catchError返回和上游一致的类型或者干脆在catchError里只记录日志再重新throw原错误final result await fetch() .then((v) v 1) .catchError((Object e) { print(记录日志: $e); return 0; // 和上游int保持一致 });我把这个教训记在了笔记里catchError不只是处理错误的函数它还是一个参与链路值传递的回调。忽略返回类型就是在给自己埋雷。4. Future.wait、Future.any与串行拼接多任务协作的三种姿势4.1 Future.wait并行聚合业务里最常见的场景是同时发好几个请求全部返回后再做后续处理。用Future.wait可以一次性等待多个Futurefinal results await Future.wait([ fetchUserInfo(), fetchBannerList(), fetchRecommendList(), ]); final userInfo results[0] as UserInfo; final banners results[1] as ListBannerItem;Future.wait传入一个Future列表返回一个以列表为结果的Future。注意这几个任务是同时被安排出去的它们运行在同一个事件循环里但因为耗时操作通常是IO等待CPU并没有被阻塞所以相比逐个等待能明显缩短总耗时。这里有一个需要精确理解的行为如果其中任意一个Future抛错Future.wait会以这个错误作为最终结果失败但默认情况下它并不会立刻失败——它会先等所有任务都跑完再把第一个遇到的错误抛出来。这个等齐再报错的行为由eagerError参数控制默认是false。如果你希望某个任务一失败就立刻返回、不要等其它任务可以显式传eagerError: truetry { final results await Future.wait(tasks, eagerError: true); } catch (e) { // 出现第一个错误就立刻走到这里 }另外即使Future.wait已经以失败告终其它还没跑完的任务也不会被取消它们会在后台自行结束。如果你有清理需求得自己接管那些没人等的Future。4.2 Future.any谁先回来用谁竞速场景比并行聚合少见但一旦遇到就离不了。比如你有两个数据源想要最快返回的那个final first await Future.any([ requestFromCache(), requestFromNetwork(), ]);Future.any会返回第一个完成的Future的结果其它Future的结果会被忽略。我实际项目里用它做过一种本地缓存快速展示网络数据到了再刷新的交互先用Future.any拿一个最快的兜底数据渲染首屏回头再通过其它方式把网络数据补上。不过要提醒一句Future.any只关心谁先完成所以如果有任务一直卡着不完成它会一直等下去。这种场景下最好给Future.any组合一个timeout把最长等待时间也封死。4.3 动态串行链式拼接与Future.forEach并非所有并发都是想要的。假设你要逐个上传一批文件为了避免同时打满连接通常选择串行。串行的标准姿势有两种写法。第一种是不断缩小链式调用的当前FutureFuturevoid uploadAll(ListFile files) async { var current Future.value(); for (final file in files) { current current.then((_) uploadOne(file)); } await current; }第二种是更直观的循环直接awaitfor (final file in files) { await uploadOne(file); }两者的执行效果基本等价都是上一批完成再发起下一批。区别只在于写法第二种更直观第一种能在循环中随时插入额外处理比如打印进度。另外还有一个Future.forEach它可以对集合做串行遍历。注意它的执行是逐个串行的不是并行的别被名字里的forEach骗了——它和List.forEach的语义本质区别在于带Future的处理要等回调完成才能继续下一个。5. 错误处理中那些容易吞掉异常的坑5.1 没人消费的错误等于没处理Future捕获异常的能力是有边界的。先看这段代码Futurevoid run() { return Future(() { throw StateError(运行时抛错); }); } void main() { run(); print(main结束); }Future(() ...)内部抛出的StateError会被捕获并转成Future的错误但你没有接catchError也没有await于是它就成了一个未处理的异步错误最终冒泡到Zone层面被打印出来。这个流程本身是正确的但代价是你丢失了处理它的机会。所以在生产代码里每次创建Future后都要想清楚错误消费链路没有例外。我见过一种隐蔽的写法在一个不返回Future的void函数里调用了异步方法又不加await。这种发射后不管在错误处理上等于裸奔一旦异步方法里抛错排查时只能靠看控制台日志还经常定位不到业务上下文。正确的做法是要么await它要么在函数内部就把错误消费掉。5.2 同步代码抛错与Future.sync的关系如果把耗时计算包装进Future要注意写法带来的差异Futurevoid run2() { return Future(() throw Exception(异步异常)); }Future(...)的函数体是在事件队列里执行的所以抛错是异步的能被捕获。可如果你用Future.value(compute())这种形式compute()是在参数求值阶段同步执行的此时抛错不会变成Future.error而是直接冒出来。要解决把同步计算包装成Future同时保留同步异常捕获就得用Future.syncFutureint safeCompute() { return Future.sync(() { // 这里的异常会被包装成 Future.error return riskyCompute(); }); }这个细节我在排查一个偶发崩溃时花了不少时间最后发现就是因为在Future.value(...)的参数里做了同步计算异常压根没进入Future的捕获范围。如果你要让一段代码以Future形式对外暴露优先用Future.sync而不是Future.value(表达式)。5.3 catchError的返回值必须匹配下游类型前面提过一次这里再展开讲透。catchError回调如果不注意返回类型很容易制造出新的类型错误Futureint query() async throw Exception(query失败); final value await query() .then((v) v 1) .catchError((Object e) { print(记录日志: $e); // 注意这里如果直接return null或者不return // 下游拿到的类型就会变成null/dynamic });正确的恢复写法是返回一个同类型兜底值或在catchError内部继续throw同一个异常交给更外层的await处理。我自己习惯的策略是能用try/catch就用try/catch尽量避免链式catchError因为catchError的类型匹配太容易被忽略尤其是在链式调用较长、回调返回类型不明显的场景。5.4 错误恢复的三条路实际项目里处理Future错误我一般按三种情形选择策略直接失败catch里记录日志然后重新throw把错误交给调用方统一处理。适合业务上需要上层感知错误的场景。兜底值返回默认值比如网络请求失败返回空列表保证UI不至于崩溃。适合宁可展示旧数据也不能白屏的场景。重试降级失败后重试几次再不行就走缓存或备用数据源。重试的简单实现可以写成一个通用工具函数FutureT retryT(FutureT Function() task, {int times 3}) async { for (var i 0; i times; i) { try { return await task(); } catch (e) { if (i times - 1) rethrow; await Future.delayed(Duration(milliseconds: 200 * (i 1))); } } throw StateError(不可能走到这里); }三层策略都做对之后Future的错误处理才算真正闭环。别指望所有错误都能被某个全局配置统一兜住该在业务层处理的一定要在业务层处理。6. 查漏补缺超时控制、测试技巧与Stream的边界6.1 给Future加超时timeout的正确用法任何Future都可以用.timeout()限定最长等待时间final data await fetchData() .timeout(Duration(seconds: 3), onTimeout: () defaultData);这里有一个必须知道的坑timeout超时后并不会取消原来的Future它只是让等待方先返回结果。原来那个Future会在后台继续跑完成后进入无人认领的状态。如果它最终抛错仍可能触发未处理错误。所以超时后如果原任务有副作用比如写日志、清理资源最好在onTimeout回调里额外处理或者在上游Future内部自己加上取消逻辑。6.2 测试Future时怎么跳过真实等待单元测试里如果直接写await Future.delayed(...)测试会真的等那么久既不科学也拖慢CI。最常用的办法是把延时通过参数注入让测试环境可以替换FutureString fetchWithDelay(Duration delay) { return Future.delayed(delay, () result); } // 测试里传 Duration.zero final result await fetchWithDelay(Duration.zero); expect(result, result);如果是Flutter的widget测试则可以用tester.pumpAndSettle()推进虚拟时钟而不是真的等待。测试异步代码的另一个要点是test函数本身要标记为async并且在断言前await所有Future否则测试可能在Future完成之前就结束了。这一点我在早期写测试时吃过不少亏。6.3 Future与Stream的分界线学习Future的时候有个无法回避的问题什么时候该用Stream我的判断标准很简单一次性结果用Future多个持续到来的结果用Stream。比如一次查询、一次登录、一次文件读取全部是Future而实时数据推送、进度上报、用户输入事件这些一直在产生数据就该用Stream。很多刚入门的人把Future当万能工具用遇到轮询也硬用Future定时递归代码很快就绕成一团。记住Future是单次契约Stream是持续契约边界清晰了代码自然清爽。6.4 回头再看学习Future的三点心得写这篇笔记时我重新翻了不少之前写的异步代码给自己总结了三条经验。第一条先画执行顺序再写代码。凡是涉及多个Future交互的场景先在脑子里过一遍事件循环的队列顺序能避免大量奇怪执行顺序的bug。比如你写了一个Future下一秒又更新UI结果UI更新反而先执行了这就是没想清楚微任务和事件队列的顺序。第二条错误处理永远比正常流程更值得提前写。Future的错误一旦没人消费排查起来比同步异常痛得多因为它不会在出错那一行停下来。我现在的习惯是任何对外暴露Future的函数都要在文档注释里写明什么情况会抛错并且保证调用方有明确的消费路径。第三条不要因为简单就绕过原理。async/await写起来太顺手了顺手到很多人忘了它背后还是事件循环。真遇到诡异问题时回到底层队列模型去推演往往几分钟就能定位。后面我打算把Stream单独开一篇笔记来写因为连续数据流的消费、广播、订阅管理等跟Future完全是另一套思维。先把Future这一篇沉淀下来也算是给异步这块画上一个阶段性的句号。