为什么需要async关键字？

[gqqnb]

我知道如果一个方法里，有使用await关键字，那么这个方法就必须被async修饰。

既然如此，C#编译器可以自己查看一个方法里有没有await，有的话就自动加上async，不需要人手工加了，也不需要多增加这么一个关键字。

为什么微软没有这么做，不让C#编译器自己添加标识，而是引入一个新的关键字并让程序员手工添加？

[以专业开发人员为伍]

await 是一个诡异的关键字，它的逻辑是“如果Task的子线程尚未结束，那么注册给子线程中在其结束之前再回调 await 这一行开始的所有代码；如果Task对象的子线程已经结束，那么在当前父线程中调用 await这一行以后的所有代码”。 await语句后边的代码，即可能在子线程中执行，又可能在父线程中执行。这样，await其实就是一个不直观的东西。那么有个“帽子”（async修饰符）就是让你一看到这个，就知道这个方法跟普通方法调用逻辑不一样，“千万不要把它当普通方法调用啊！”。 编程中尽量不要使用async/awiat。你应该使用明确的异步回调语法，这样你的思维上就有着更干净、无条件的异步程序设计逻辑。而async/await希望你在与同步程序几乎风格不变的代码上、产生异步调用的类似风格，同时又“忽而同步执行此回调、忽而异步执行此回调”。这其实没有给程序员提高开发效率，更无法确保可调试。 开发中不要使用async/await。应该使用.net4.0以前的异步编程语法。

[以专业开发人员为伍]

如果不加 async 关键字，实际上会扩大这种诡异性，造成“普通的方法”也成了诡异的“分不清此方法是异步还是同步”了。这肯定不行。这其实就相当于那句老话：“一个谎撒出去之后，需要用另一个大谎来圆”，是自相矛盾的。实际上async/await 是个混乱的东西，为了少写几个嵌套回调委托的“大括号”（异步回调风格的代码），就引入了“连方法的源代码自己也根本看不清楚是在父线程还是子线程执行回调”的机制，这是.net4.5的一个败笔。

[以专业开发人员为伍]

如果你让程序设计师去画出程序的流程图、时序图，就看的很清楚了。 实际流程是异步的。不管这个异步回调（await语句自身以及随后的所有的所有语句）是在父线程中调用还是在子线程中调用，那么异步回调的程序的流程图和时序图都是与传统的顺序执行的流程图和时序图有天壤之别。让程序设计师意识到这一点，要比给它什么 async/await 语法来简化一点，要重要100倍。而这个语法却是混淆流程图、时序图的。 .net中许多好（至少是出发点是好）的东西，但是因为“太复杂”而反而成了微软开发平台技术的埋葬者。我的分析，这个async.await 的好处只有它宣传的 10%，剩下的 90% 都是造成使用它的程序设计师的产品的分化瓦解的诱因。不论是 c# 还是 java 语言，谁用它谁会尝到它对设计师队伍的危害。

[泡泡龙]

楼上说的很有道理，不过，C#发明这两个关键字倒是挺适合不会异步编程的业余弟兄

[lincolnandlinda]

为什么要手动添加Async和Await关键字, 主要是兼容性问题, .Net4.0以前的代码可以直接调用一个返回Task的方法, 如果把这些代码放到.Net4.5中编译, 编译必须通过. 另外, 加上Await关键字的方法调用和原先不加Await的方法调用其含义是不同的, 所以必须要程序员手动区分. 至于是否应该在.Net4.5中使用Async和Await, 那就因人而异. 我个人推崇使用, 因为Task本身提供的Continuation使得代码很难读,特别是有许多链条的时候. 我更喜欢清爽整洁的代码, 此外异步的方法测试也方便许多,因为MS的Testing Framework提供了异步支持.

[gqqnb]

引用 1 楼 sp1234 的回复:

await 是一个诡异的关键字，它的逻辑是“如果Task的子线程尚未结束，那么注册给子线程中在其结束之前再回调 await 这一行开始的所有代码；如果Task对象的子线程已经结束，那么在当前父线程中调用 await这一行以后的所有代码”。 await语句后边的代码，即可能在子线程中执行，又可能在父线程中执行。这样，await其实就是一个不直观的东西。那么有个“帽子”（async修饰符）就是让你一看到这个，就知道这个方法跟普通方法调用逻辑不一样，“千万不要把它当普通方法调用啊！”。 ……

哦，了解了。。因为async方法的执行逻辑不太一样，要在源代码的级别上给程序员区分。