@statumer 我原先也完全是你这个理解思路，直到我在这一楼层里面看到了有人说 Go 语言的协程是可以切换上下文的——

https://www.jianshu.com/p/fb1ccbd0d0ff

我 tm ，瞬间五雷轰顶，并且明白了为啥 Go 吹那么多的原因。引用我 125L 的观点：

> Go 这种内置协程时间片切分的机制，在我看来，是一种工程实践上的妥协。
> 无论多轻量级的切换，一定是耗时的。减少不必要的切换可以使得总体耗时降到最低。
> 如果能控制 IO 非阻塞让渡控制权，而且每对 IO 之间的操作都比较轻量（微妙级），就完全可以只在 IO 上切换。这样总体效能是最高的。
> 但是工程上不能保证所有类库都这样，也不能保证所有程序员都写的对，所以 Go 的这种协程才有用吧 hhh

所以本质上这是一个，因为不会用 event loop 的程序员太多了，Go 语言大爷们就说：算了，你们这群傻逼，干脆我语言创造一个比系统线程更轻的协程给你们用算了。

----

所以总结一下，Go 语言的协程和其他语言的协程是不同的。C++、Python 这种经典语言的协程 tm 根本不可能内置 Go 虚拟机的时间线分片。JVM 和 C# 也从未想过要这么干。微软的 Fiber 还差羽而归。因为它们发现，替程序员越俎代庖搞这种抽象，吃力不讨好。反正追求性能的有 event loop 或者基于 event loop 的单线程协程，为啥还要搞个不上不下的多线程（有上下文切换）的协程呢？

毕竟任何上下文切换，哪怕你说 Go 协程切换只要三个寄存器，tm 还是实打实有这个耗时的啊。
----

但是在一个没有泛型被认为是大道至简的语言里面，这种独一份的奇葩设计也没啥可奇怪的。