@byte10 之前好多次没回复我，还以为你把我 block 了 :joy: ，感谢回复！

> 但还是保持一些观点，如果放在业务层去使用，大部分开发人员还是会用 协程去写同步代码，那么就跟你省内存的初衷违背了。

其实你还是误解了，我解释过好多次了，框架本身是提供了逻辑协程池的，用户仍然是同步代码，比如 http handler ，这个跟使用标准库写同步代码没什么区别:
https://github.com/lesismal/nbio-examples/blob/master/http/server/server.go#L19

nbio 里，每个 http 请求到来时取一个协程处理，这个请求处理完了这个协程可以继续服务其他请求，并不是每个连接固定、持续占用一个协程。

c/cpp 那些框架，线程太贵，所以线程池数量少，很多框架是逻辑单线程，所以需要各种回调。
但 golang 协程不一样，协程便宜，百万链接那是协程数量太大了，但是 1-10w 协程压力不大，所以逻辑协程池 size 弄个几千几万个协程是可以的。而且 golang 其他的 io ，比如到数据库，也是有连接池限制的。即使 100w 个逻辑协程也是可能被数据库连接池卡着等待，所以太大逻辑协程数量也意义不大，反倒是几千几万这种协程池数量，已经足够动态均衡了。

总结下就是，逻辑协程数量多但是可配置、不好过硬件能力：
1. 如果是快业务，每次请求处理很快、协程能很快释放给其他请求去复用
2. 如果是慢业务，逻辑协程再多也是要被阻塞，但逻辑协程数量通常远多余下游（比如数据库）的限制，所以仍有足够的空闲协程处理其他请求


所以对于通用需求，根本不存在你先入为主地以为的那种用了 nbio 就要写回调的问题。

而有一些需求，即使是用标准库，也可能是需要写回调的。特殊问题，特殊处理就可以了。

比较均衡的并发模式是：
1. 纵向的不同分层上（比如网络库、框架、业务层），各层限制好自己的资源使用，比如协程池、buffer pool
2. 横向的不同模块上（比如 A 功能 B 功能 C 功能），各模块限制好自己的资源使用，比如协程池、buffer pool


架构是灵活的，人也应该灵活，欢迎来试试 nbio