我用 Omnigraffle （惭愧，是盗版）。公式用 LaTeXit

https://i.imgur.com/J4q4rL9.png

不过我觉得 Visio 也能画

16 寸还是小了点。27 寸屏幕还是很给力的（写代码）

“闪瞎眼”、“偏冷”——外接屏幕我反正一直开护眼（偏暖）的，习惯了

@liuguangxuan 再举个例子，你可以看看 pybind

https://github.com/pybind/pybind11

这东西配合 cmake 可以很容易写一写 python 算法扩展类型的项目，然后用比如 FastAPI

https://fastapi.tiangolo.com/

就能发布为微服务给前端应用使用了。

----

所以真正的技术是没有那么多条条框框边界的。说实话 pybind 封装算法，也应该封装还算快的算法（比如 1ms 以下延迟）。如果是几秒以上的算法，我个人会直接用 c++ 写一个命令行程序，stdin 读入，然后 fastapi 开 asyncio.subprocess 直接对接到前端。

@liuguangxuan

1. 不用太纠结网络编程本身。能看懂各个库的原理（不是代码），尝试写一点小代码（实验性）调通对应原理，就 okay 了。没必要封装个什么新轮子。
2. 甚至其实你用这些网络库本身能写出来应用已经是调通了对应原理了。调试过程中你就实践了这些知识。
3. 我不知道网络编程天花板在哪里，因为大部分人都是懂了你说的这些去做别的上层应用的，而且比 CRUD boy 强多了。所以网络编程是提高你的上限去江河湖海耍，而不是让你建一个鱼塘在里面玩的。
4. 你对于 C++ 的疑问也是同样的思维误区。C++ 在很多很多应用里面都会用到，比如低延迟交易、高吞吐量的业务服务器、图形学相关（比如游戏引擎）、大型专业软件（比如 WPS Office 、Photoshop 等）、数据库系统（你可以不用写个数据库，但你说不定有朝一日需要给 mysql/postgresql 写插件）、算法（传统、AI ）等都是重要的组成部分。

我觉得老哥你的主要关键误区在于，总觉得吃透 “一项技术” 能行了。但现实不是这样的。要离开 CRUD boy 的层次，你需要的是对各种技术都有涉猎，然后再把它们融会贯通，最后会在解决实际问题的部分使用最合适的技术。能用别人的系统（比如 Redis ）就不要自己手撸，能用别人的类库（比如 muduo ）就不要自己再用 epoll 重新造一个。

有没有一种可能，通常而言“网络编程”指的是用你说的这些个程序来写性能不错的应用程序。。。

@WOLFRAZOR 不需要痛苦，现在有更好的替代品了。你可以试试 Obsidian

https://i.imgur.com/hZCa1NB.jpg

@WOLFRAZOR 当年 Typora 是大段公式的唯一选择。

https://tva1.sinaimg.cn/large/e6c9d24egy1h3jgs9r7a1j213n0u0jv6.jpg

自信点，Linux 桌面小问题都多。而且社区都不太在意这种小毛病。

@maichael 这个真的是深有体会。。。有些人牛逼吹得自己能做很多项目，其实啥也不会。

@yogogo （其实吧。。。其实吧。。。其实吧。。。

背书背出来的知识，在实践中很难立刻融会贯通的。还是做项目学到的知识更扎实。

毕竟能招到宝马谁想要桑塔纳 hhh

不会点原理的话 95% 的代码工作能胜任，但是出点奇怪的 bug 就搞不定了。

总之如果只看名词不看实际（实现方式），各种语言、框架的并发就是大坑，不同概念层出不穷，会让楼主混乱的。

如果楼主不想继续纠结这么多乱七八糟的概念，建议左转 Go 语言。那边的 Goroutine 中的同步代码 = Event Loop + 协程（相当于 Python/JS 手动 async/await ） + 线程池。实际上完全解决了楼主你书里面看到的问题，但是其实你书上的概念一个都套不上去，因为它直接从 vm 层面给你扬了这些概念（笑

虽然你像我这么分析还是能对应到你书上概念的

... 然后书上说的不错，但是没有告诉你的是什么叫“时间太长阻塞”。

实际上你看到的 “每个事件处理都用线程池里的线程去处理” 太泛泛了。具体而言，一般我们都是把 CPU 时间开销大的逻辑丢进线程池然后 await 的。比如算一个 PageRank 分数之类的（笑）。

上面的仁兄提到了 Actor model 。我很感动居然还有人知道这玩意儿，但实际上这玩意儿写普通的业务逻辑不如 async await 高效。举个例子，如果你要读数据库，在多线程 Actor model 下你要怎么做？难不成直接同步阻塞等数据库结果？那不好意思，在大部分语言（ C++/Java/Python ）中，你又阻塞了一个线程池。纯粹的 Actor model 要求你业务代码把数据库请求 send 给 DBActor ，DBActor 应该是一个负载均衡，后面接着一串多线程的 DBActors 。然后 DBActors 阻塞读写，出来结果再 reply 到业务 Actor 。总之纯粹的 Actor model 写业务代码挺麻烦的。

但是 Actor model 上限很高的，是屠龙刀。它能保证每个 actor 同时只有一个线程在跑，直接保证所有数据的线程安全。这种屠龙刀就不该用来写普通的业务代码。
----

综上所述其实 async / await 写业务代码其实很舒服的，在大部分语言中你不会喜欢其他模式的。

除了 Go 语言。

Go 语言是个工程妥协性非常强的语言，为了解决普通程序员不那么高明这一“人力 BUG”，它做了一些在我看来很丑陋的（但是确实能解决不那么博闻强识的程序员写出来的代码问题）选择。比如它会自动把同步的等待代码直接切出来控制权，强行在 Go vm 层面自动地把同步代码给打断等待。相当于你写了同步等待的网络 /文件 IO ，它自动翻译成 async await 了。这个确实屌，不得不承认，虽然在我看起来很丑陋——

这意味着程序员并不能 100% 控制 Go 语言的实现，你写个比如 PageRank 的算法可能比不上 C++，因为有一堆你不知道它会干嘛的额外动作。

当然，我这么评价 Go 语言，是因为我从线程池、Event loop （ select epoll ）、Actor model （ Akka 或者我自己 C++ 手撸的）、callback 之类的东西我都用过。C++、Python 、Scala 、JS 我都写过不少项目。嘛，没那么博闻强识的程序员确实 Go 语言包办更舒服。

其实吧，业务代码没那么多 CPU 时间很长的片段的。一般都是直接写一点数据处理，await 数据库 /文件 IO 。

好处实在太大了。因为在线程池模式下，无论是数据库还是文件 IO 都会阻塞一个线程，也就是说就算你业务逻辑再简单，也会耗尽线程而无法提高并发。现在直接 async ，阻碍你并发的只有后端数据库和网络的速度。网络速度可以随意 100MB/s ，数据库可以集群（提供更快的读、更慢的写），这样就非常 nice 。

虽然楼主说的确实有道理，不过我个人确实不需要呼吸灯这种玩意儿。。。

毕竟电脑上该登陆的都登陆了。微信是肯定会打开的，那么大部分消息也就不会没看到了。