Task<T>与 I/O 阻塞问题无关。它就像打开一个线程（加上额外的效率和功能） - 但它仍然会导致线程消耗 CPU 量子等。
不必要。基本上有两种Tasks：执行一段同步代码，并在该代码执行完成时完成。这种Task块aThread从开始执行到完成（成功与否）的整个时间。
但还有另一种Task：当某事发生时完成的。这种Task是 .Net 4.5 和 C# 5.0 大量使用的内容，并且它不会阻止Thread（至少不是直接）。你可以创建这样的Task自己使用TaskCompletionSource<T>.
（另一点是，被阻塞的线程不会消耗任何 CPU，但这与这里无关。）
是不是就像创建一个Task<t> with ContinueWith?
Yes, await t非常类似于t.ContinueWith(rest of the method).
术语是不是很混乱？异步方法用于 I/O 操作（进行 I/O 操作时有零个线程在等待，并且没有线程处理它）。但是将代码（使用异步）调用为：异步方法有点令人困惑。你不觉得吗？因为我假设有另一个线程正在执行。
我没有看到混乱。经典的异步方法（例如BeginRead();这称为“异步编程模型”或 APM）是一种启动操作并在操作完成时收到通知（通过回调）的方法。现代异步方法（例如ReadAsync();这称为“基于任务的异步模式”或 TAP）也是一种启动操作并在操作完成时收到通知的方法（使用await).
在这两种情况下，都可能在方法返回之前执行一些代码（第一个之前的代码）await在 TAP 案例中）。
在这两种情况下，通知结果的常用方式不会阻塞任何线程（APM 的回调、await对于 TAP）。
在这两种情况下，如果需要，您可以使用阻塞等待（立即调用EndXxx()APM 方法，Wait()对于 TAP）。
这两种情况都可以用于在后台线程上执行同步代码（BeginInvoke()关于 APM 的代表，Task.Factory.StartNew()对于 TAP）。
再说一次，我没有看到混淆，这两个模型对我来说看起来非常相似。
