好多问题呀，开始回答或者提问前，其实可以看看问题本身是不是有问题，像黄执中一样。
------
【资料图】
这个问题首先前提就有问题，谁说协程那么好的？任何技术肯定都有自己的适用场景，这种通用层面的技术则更是了。
协程本质上就是由用户代码主动在某个时间点出让 CPU，可以在任何一行出让，当然语言层或框架层的协程一般会在原本是阻塞函数的调用内部，让出 CPU 资源，不阻塞当前线程。
当然像 go 这种协程做的特别牛逼的，牛逼到它自己都不想承认自己是协程的语言，就另说了。
所以协程一般适用于 IO 密集型的高并发场景。
你要说就完全 CPU 密集型计算，那还不如开你 CPU 核数那么多线程呢，开了协程反而不能并行了，还多了协程间切换的损耗。
所以协程那么好，这句话就可以否了，同时也顺便拿出了一个场景，说明用协程替换线程是负优化的，自然协程也不能完全替换线程。
------
再有，刚刚是站在应用程序角度考虑，要分场景看是使用协程还是线程。再从操作系统层面考虑，协程就根本无法替代线程了。
你想，协程需要自己主动出让 CPU 资源，那要是操作系统使用协程来运行应用程序，那万一应用程序自己一直不出让 CPU，也不调用能产生阻塞操作进而间接出让 CPU 的代码，那不就坏事了。
再有，协程本身的优势在于切换成本小，本质是因为栈小，而且也不需要切换页表。
那要是操作系统真的拿协程来跑多应用程序，这些优势也就不复存在了，而且如果协程实现在了内核态，本身从用户态陷入内核态的切换也少不了。
所以本来协程有的优势，在这里全没了，还极大增加了不公平性。
------
最后，这俩事情本身就不好讨论替换这一说，因为他们本质都不一样。
协程说白了就是一段串行的指令流，只不过中间哪个地方往哪跳的逻辑，被封装在了 "协程" 这个概念里而已。
再者，协程本身也是要跑在线程中的，需要有载体，他们二者本身就是相辅相成的关系，何来替代呢，更别说完全替代了。
有时候，了解清楚一项技术的本质，就能更好看清这些问题的荒诞了。
今天阳了躺在床上实在无聊，就挑了个知乎上的问题回答了一下，看好多回答都没说在点子上，就码了这些字，感兴趣的同学可以点开阅读原文看看。
