如果是大数据场景，确实应该做流控的，不过这里只是演示demo，为了简单好理解，所以没有考虑这么多，你能够自行加上，说明你理解的还挺深彻的，不过为了避免复杂化，这个PR我可能不考虑合入了，感谢您的提交。

非常感谢您的回复！

我很同意您的看法，提 PR 的时候也很犹豫，将 examples 弄得太复杂，对于入门者而言会增加理解门槛。
后来想着还是提交一个 PR，希望能获得一些 review 反馈，也给后人留下一些参考。

在此我想分享一些我作为框架初学者的学习经历：

最初从 github 中搜索到 libhv 项目，阅读了 examples 后发现框架使用起来很简洁，于是想研究一下框架的吞吐性能表现。起初尝试了 tcp_proxy_server + iperf3 测速的场景，但发现会频繁触发缓冲区超过上限，导致连接被关闭。当时非常困惑，直觉认为是框架的 bug。后来发现中文 Wiki 的一条 FAQ 解释了这个问题。 但在全网查找资料，也包括所有 examples 和用户案例中列出的项目， 没有找到任何开源的 libhv 转发场景流控的参考实现。

之后开始阅读 libhv 的代码，根据 FAQ 中的提示尝试实现流控特性。一开始的版本实现为了 libhv 的内部函数。后来意识到 libhv 的接口很完备，直接将流控实现在上层应用中也没有什么阻碍，于是重构成了当前的状态。

可能在一个刚接触 libhv 框架的初学者的视角来看，实现流控是一个比较令人困惑且容易出错的事情 😂

实现的过程中在思考一个问题：考虑到缓存是框架内部分配和管理的，而流控的本质是缓存管理，即：将缓存控制在一个安全区间。或许流控特性也可以内置在框架中，作为一个可选功能提供。比如为 hio_setup_tcp_upstream 函数增加流控特性，或是实现为独立的函数。

不知道您的看法如何？

很好的建议，对于upstream转发功能来说，hio_write是内部调用的，流控确实可以在内部做掉，在upstream_on_read里根据hio_write的返回值判断系统发送缓存区已满时暂停读，在upstream_on_write里判断写缓存清空后再重新开始读，期待你的PR。