@abersheeran 缺陷之二再补充一下说明：无栈协程需要程序员自己时刻牢记自己每一步操作是否会带来同步 IO 操作。上述只是拿了文件举例，实际上应该有更多的操作是同步的，都需要程序员自己去权衡线程池如何安排。

如上所述的性能差异说到底就是有栈协程和无栈协程的性能差异。

我个人选有栈协程，也就是 golang 这一套。因为写代码方便，有栈协程无感染性。虽然我一直沉浸在 Python 的无栈协程里跑不出来。

无栈协程的性能缺陷：文件 IO 需要走多线程通过回调包装成异步的，如果细扣到有栈无栈这个地步，那么这个包装其实还是很浪费资源的。而有栈协程不需要这么包装，在有栈协程里调任何同步 IO 都没事，都可以挂起。
缺陷之二：感染性。如上述，文件 IO 之类的同步 IO 必须包装起来，但是传统编程里很多文件 IO 是程序员自己都不不注意的，比如 file.exits()、path.is_dir() 之类的。如果要把无栈协程的性能发挥到极致，这些必须都包装起来。但如果只是简单粗暴的多线程跑，线程切换其实比这种少量 IO 还要耗资源。这里就很难优化好。

老哥你这个帖子没啥人回复，估计是因为学 golang 的人跟我想法差不多，都更喜欢有栈协程，所以对你这个兴趣不大。

@ClericPy 你说测这个啊，那的确是 aiohttp 更快，毕竟有 C 加持。不过一般发请求的客户端速度瓶颈都在目标服务器啊。

@ClericPy 不对吧。我记得 aiohttp 的客户端性能没比 httpx 好到哪儿去。也就服务端性能不错。

httpx yes ！

哈哈哈，三连了。

还有，大家看不下去你的故事，大概率不是因为这种格式的问题，而是你的故事的问题。

文字是最忌讳上来对这个人物一顿背景描写的。很枯燥，哪怕你这个不是个技术文章，也没人会愿意看。动画片或者电影能这么干，是因为有画面，通过画面能缓解这种枯燥感，但文字没有画面，所以必须稀释这种大篇的背景设定介绍。

写作是一件很累的事情，比写代码可能更加费精神。代码都写的不咋地，就别没事跨行作战了，浪费你自己时间。

我觉得直接单刀直入解决问题，是好的技术博客。或者从浅到深的叙述，也是好的技术博客。显然，你这个两个都不算。

单刀直入有很多，就像 StackOverflow 各种优秀问答。从浅到深，我觉得王垠那一篇讲述 S 运算符的 http://www.yinwang.org/blog-cn/2013/03/08/on-syntax 就很妙，虽然我还是不认同他最后一句话，但前面对 S 表达式的叙述很好，由浅到深、直指本质。

@xinyana 微信是独立的。QQ 比微信好多了，至少不会打死机器人。另外，微信在腾讯内部也是天龙人，都不会带其他事业群玩的。

任何语言，不 seek 只用 write 都是会保持写入顺序的，但是实际落盘的扇区不一定连续。扇区不连续就意味着读的时候磁头还会做无意义的移动，而不是很顺畅的从头划到尾就行了。

你可以试试用 Python 在一块垃圾机械磁盘上不停 write，效率还是不错的，我在公司发给我的垃圾电脑上试过。

另外，如果你使用过 Windows，那么应该记得 Windows 有一个系统功能就是整理碎片。这个碎片就是指扇区的分布太散，文件读写的时候会慢。

Python 是一个很“愚蠢”的语言，如果你在函数里写 import，那么每次执行这个函数它都会真的执行这条语句，虽然 import 有缓存，但是也会影响速度的（一点点）。

https://aber.sh/articles/sentry-wechat/ 之前也用 Serverless 做过企业微信消息通知。说实话，如果微信能加这个机器人我肯定不会这么反感微信。

你这个“编译器应当优化尾递归”的说法放在 Py 里可能可以，但是放在 JS 里绝不可能的。JS 的历史包袱可是最重的。

包括国内那台，都是网络代理……

@DM1 对对对，感谢。

序列化和反序列化功能肯定还是要包含在生成的 Python model 里的。

@FucUrFrd
@yunyuyuan