C#函数返回值类型Task和T有什么区别？

[测试出生的码农]

比如： public Task<string> test1() { ...... } 和 public string test2() { ...... } 有什么区别？

[以专业开发人员为伍]

这个时候如果你需要等待异步回调那么就直接调用它 --> 这个时候如果你不关心等待回调那么就直接调用它 举个例子，假设我们要返回当前 static 的一个变量值，但是当其没有初始化的时候需要调用 WebClient.DownloadStringTaskAsync 方法来异步（注意是不阻塞）访问远程服务来获得初使配置值，可能会写类似这样的代码

private string _config;

public async Task<string> GetConfigString()
{
    if(_config == null)
        _config = await new WebClient().DownloadStringTaskAsync("http://1.2.com");
    return _config;
}

这个方法，返回本地的一个字符串，尚且需要清爽干脆地 async/await 代码才能奏效，可见这种机制现在是多么地好用！未来会跟普通控制流语句一样成为编程必备机制，否则一个人就会如“骑着牛进城”一样地看其它编程同事。

[以专业开发人员为伍]

再强调一遍，Task 就是不等待，而 await 就是回调。二者综合起来的最基本的结果，就是把老掉牙的“子线程+死循环+Sleep”扔掉。

[测试出生的码农]

引用 30 楼 货郎大叔的回复:

Task是异步执行……

还真没发现他是异步的，，，能举个例子吗

[测试出生的码农]

引用 40 楼 sdghchj 的回复:

研究一下两者区别

public Task<string> fun()
{
      //一大堆代码
      
     return Task.FromResult("hello world");   //
}

public Task<string> fun()
{
     return Task<string>.Run(()=>{
           //一大堆代码
           return "hello world";
     }); 
}

如果并不涉及异步函数调用，并没有必要将返回值搞为task类型，效率又低。

下面那一段代码，靠的是Task.Run()来实现的异步，跟返回值类型Task<string>没有关系对吧？Task<string>主要是为了配合Task.Run()的返回数据。
也就是说，public Task<string> test()本身并不能实现异步。另外如果不涉及异步操作的话，功能上跟public string test()没什么区别，是么？

[以专业开发人员为伍]

晕！这还说不明白？ 在接口方法返回值上声明 Task 关键字是一种协议，说说这个方法可能不等待。谁说有没有子线程、用不用 Task.Run、有没有标题党用异步语法来行同步阻塞之实？ 如果你不能区分“协议”，就好像不懂“说”与“做”的区别一样，以为只要抠字眼儿就能理解事情、而不需要看它实际是怎么做的，这就是基本的“三观不辨证”或者“三观过于迂腐”的问题了，是属于只见树木不见森林的问题，不是技术问题了。

[以专业开发人员为伍]

你说接口协议“本身实现功能”吗？这看上去是小事儿，其实是对所有“知与行”的逻辑都存在着基本的理解问题，都不能通。

[stherix]

Task async await本来就是三位一体的 缺少任何其中一个,那么是无法编译,要么就还是一个同步方法,实现不了异步功能 Task<T> fun()就是一个同步方法,返回值是Task<T>,而不是T 而async Task<T> fun(){ await xxx } ,是异步的,返回的是T,而不是Task<T>

[测试出生的码农]

引用 48 楼 以专业开发人员为伍 的回复:

晕！这还说不明白？

在接口方法返回值上声明 Task 关键字是一种协议，说说这个方法可能不等待。谁说有没有子线程、用不用 Task.Run、有没有标题党用异步语法来行同步阻塞之实？

如果你不能区分“协议”，就好像不懂“说”与“做”的区别一样，以为只要抠字眼儿就能理解事情、而不需要看它实际是怎么做的，这就是基本的“三观不辨证”或者“三观过于迂腐”的问题了，是属于只见树木不见森林的问题，不是技术问题了。

看来要学的东西还很多，我先自己尝试在项目中用用看，多谢！

[测试出生的码农]

引用 50 楼 stherix 的回复:

Task async await本来就是三位一体的
缺少任何其中一个,那么是无法编译,要么就还是一个同步方法,实现不了异步功能
Task<T> fun()就是一个同步方法,返回值是Task<T>,而不是T
而async Task<T> fun(){ await xxx } ,是异步的,返回的是T,而不是Task<T>

OK，多谢！

[還是]

了解一下观察者模式，注册一个监听，有返回值时通知。具体什么时候获取通知，通过Task<T>这个玩意获得。 具体是Task里面实现的， 可能有个线程来 where (1) { //判断通知到达 ... } 而T只是一个类型，value值。 c#好久没写了，看上面的说明，大致的理解。

[sdghchj]

研究一下两者区别

public Task<string> fun()
{
      //一大堆代码
      
     return Task.FromResult("hello world");   //
}

public Task<string> fun()
{
     return Task<string>.Run(()=>{
           //一大堆代码
           return "hello world";
     }); 
}

如果并不涉及异步函数调用，并没有必要将返回值搞为task类型，效率又低。

[xiaoxiangqing]

[以专业开发人员为伍]

比如说你设计一个功能操作接口方法

public void DoSomthing(int a, string b, Action<string> callback);

这个方法告诉说有可能以异步方式执行某功能，执行完毕则回调 callback 方法，难道你认为实现者就不会写成

public void DpSomthing(int x, string y, Action<string> callback)
{
    var z = x.ToString()+y;
    callback(z);
}

了吗？ 异步就是一种语法形式，谁跟你说必须用子线程？ 甚至以（上述）同步顺序操作来实现异步接口功能声明，这也偶尔会看到。更别说有些技术（今天看来）比较陈旧的人还动不动就无意义地些什么 Sleep 阻塞语句了！所以异步是一种编程模式，是协议，不代表着实现返回 Task 类型方法的时候，那个人真的就会设计。

[以专业开发人员为伍]

你看到了在返回部分声明为 Task 关键字的方法，你就知道该用什么编程设计模式，这就是 Task 的作用！ 首先要搞懂 Task 的真正的实现方式。不要纠结什么人有可能将来使用诡异地低级的非 Task 的方式来实现声明为 Task 的方法。你只要按照 Task 的协议来使用这类方法就行了。

[正怒月神]

Task<T>和 Task 类似于 返回值是 T和 void的概念。

[以专业开发人员为伍]

比如说你去淘宝店铺买东西，你认为“快递送到我们小区门口的时候，菜鸟驿站会给我发短信让我去取件”。这是正常思维方式。 但是假设淘宝店铺非要以以垃圾的阻塞同步方式，如果你个人不去菜鸟驿站去取完件、则全国的其它淘宝用户就没办法下订单、派件，如果淘宝是这样搞的，那么这是淘宝的损失，不是你的损失。 你如果遇到一个由有经验的设计师设计为 Task 的接口、但是由比较差劲的程序员实现为阻塞式的过程的方法，你还是按照接口定义编程，你懂得 Task，这就行了。至于性能损失，无感知的人也就想不到有什么损失。

[weixin_44858208]

感觉并没有起一个新的线程，不然更新主线程的控件

[balancergh]

带task的应该是异步。

[OrdinaryCoder]

引用 54 楼 還是 的回复:

了解一下观察者模式，注册一个监听，有返回值时通知。具体什么时候获取通知，通过Task<T>这个玩意获得。
具体是Task里面实现的，
可能有个线程来
where (1)
{
//判断通知到达
...
}
而T只是一个类型，value值。
c#好久没写了，看上面的说明，大致的理解。

一看就是C++转C#

[luj_1768]

这是个模版类的声明方式，从服务器的角度，可以理解为：你的代码会通过一个公用服务编组服务器来执行调用。相关的安全性和服务能力都比简单调用强大很多。