虽然从最底层的实现上，coroutine 和 thread 类似，但他们对开发者暴露的用途不一样.

coroutine 很重要的一点是提供了在一个线程内部不同 task 间轻量级的切换。在线程内部，用户就可以根据自己的需求来协调。外部来看仍一个线程pin在一个 core 上满载，最大化性能。这个理念，在现代高性能事务处理里很常见。比如，事务A想拿锁，看到已经被事务B占了，事务A必须要 yield。这里A，B 和锁的结构可以都在一个线程内部，没有 I/O，但还是有逻辑上的 block和 yield。

至于为什么有同步，有 channel。因为 coroutine 也可以在不同线程上。一个线程内部不需要同步，但是两个 coroutine 在不同线程上就需要了。我觉得这样的抽象可以把 coroutine 和物理的线程彻底解耦开，为开发者性能优化提供方便。比如根据 task 的数量，动态分配物理线程执行，用最少的线程 (CPU cores)，做最多的事情。每个 task的开发不用特别关心需要交互的task在一个线程内部，还是另外一个线程里。

【 在 hgoldfish 的大作中提到: 】
: async/await 只是助记词，纯粹是编译器弱爆了才需要这俩。你可以试试去掉这两个助记词，会发现完全不会影响程序的可阅读性，反而更清晰了。所以在我看来，python, c#, js 还有现在 c++20 的 coroutine 都是走上了歧路。以前 python gevent 那种玩法才接近完美。
: coroutine 跟 thread 在实现上原本就是一样的，如果你不理解 coroutine 跟 thread 是一样的，你就没法理解 coroutine 为什么需要同步语义，等你写多了 corotuine 早晚有一天会出事的。试试解释一下如果 coroutine 没有 thread 的语义，goroutine 为什么要用 channel 这种消息管道，而不是直接传递值。
:
--
FROM 167.220.233.*