Flutter中带async/await的Future函数实现是否属于不良设计？

为什么用async必须返回Future？ #

async关键字的核心作用就是将函数执行逻辑包装为Future，和你用不用await无关。哪怕你在async函数里直接return一个同步的Item，Dart也会自动把它包装成Future返回。await只是让你能以同步的写法等待异步结果，但async标记已经决定了函数的返回类型必须是Future。

用await后Item是不是被“人为”包装进Future？ #

是的，但这是async关键字的特性，不是await导致的。当你在async函数里用await拿到Item后return，Dart会把这个Item再次包装成Future返回——因为async函数的返回值必然是Future类型。

Future返回类型的意义 #

Future是Dart异步编程的核心概念，它本质是一个异步操作的“占位符”：

• 告诉调用者：这个函数的结果不能立刻拿到，需要等待某个异步任务（比如网络请求）完成
• 提供统一的异步处理方式：调用者可以用await或者then()来获取最终的Item值，让异步逻辑和同步逻辑的调用方式保持一致

两种实现的性能开销对比 #

两种实现的性能差异几乎可以忽略不计：

• 第一种的async/await是Dart提供的语法糖，编译器会把它转换成类似第二种的Future链式调用（底层都是基于Future的then方法）
• 唯一的区别是第一种多了一层async函数的包装，但这层包装的开销在实际应用中完全感知不到，除非你在极端高频的调用场景下（但这种场景一般不会用异步操作）

两种实现的适用场景 #

• 第二种实现：如果只是单纯转发_itemApiClient的Future结果，不需要额外处理，这种写法更简洁，少了一层async的包装
• 第一种实现：如果需要在拿到Item后做同步处理（比如修改属性、校验数据、转换格式等），async/await的写法可读性更强，避免了嵌套then()的回调地狱

举个扩展逻辑的例子：
第一种（async/await）写法更自然：

Future<Item> getItem(String id) async{
    Item item = await _itemApiClient.getItemById(id);
    item.lastAccessed = DateTime.now(); // 同步修改属性
    if (item.isExpired) throw Exception("Item expired"); // 同步校验
    return item;
}

第二种（直接返回Future）扩展需要用then()：

Future<Item> getItem(String id) {
    return _itemApiClient.getItemById(id).then((item) {
        item.lastAccessed = DateTime.now();
        if (item.isExpired) throw Exception("Item expired");
        return item;
    });
}

总结 #

• async函数必然返回Future，这是语法规则，和是否用await无关
• Future返回类型是异步逻辑的统一标识，让调用者清晰知道需要处理异步结果
• 两种实现性能差异极小，选择哪种取决于后续是否需要扩展同步逻辑

内容的提问来源于stack exchange，提问作者DavidGetter