@zhengxiaowai 谢谢回复 我还是觉得上面说的由协程池中的任务数量来判断是否已经完成简单一点

@nuk 和四楼的一个意思 单还是谢谢回复：）

@Mitt @lesismal 谢谢你们的回复和思路

@lesismal 但是这样其实也有一个问题，就是你上面的代码示例中，协程数量是不固定的，那要是固定的协程数量怎么写比较优雅一点？

@lesismal 是倒是是 就是 pool 会有多个

@Mitt @Trim21 context 的只是起到超时或者从上到下关闭作用，并不能感知到任务是否完成吧

倒是全局使用一个 waitgroup 可以解决，只是全局变量到处飞略微有些蛋疼。。。

@Sasasu 谢谢你提供的思路，但是对你说的内容有些疑问
> 然后当协程池工作线程 = 0 时计数 +1

如何知道某个协程中任务已经空了？

@Trim21 谢谢回复 这个包可以比较好的处理情况 1 中 err 的部分，但是无法处理情况 2

如果用 sync.WaitGroup 只适合情况 1，且需要在 err 出现的时候考虑到如何 done 好像挺恶心的

@goofool 大部分代理都是失败的

@freestyle 你自己不是都说 Proxy 不同不能复用吗 😂

@freestyle 也加了 我记得源代码中 好像会解析 req.Close 把他转化成 header

@wnanbei 照你这么说的话 那等于无解了 🤦‍♂️

@freestyle 谢谢你的手机回复，但是从我目前测试结果来看 就算加了 close 的 header 也没有效果 connection 还是不关闭

@wnanbei 另外你的 direwolf 包源代码我略微看过了，是不是也存在我的这个问题？

@wnanbei #1 这好像不对啊，既然 proxy 不能复用，那你第二点说的 不管设置多大 就没有意义了吧

@index90 @icexin 感谢你们的耐心解答 我昨天尝试了使用 size/2 然后同一个 client 和 transport 之后 ulimit 调整到 2W 尝试跑了 8000W 数据没出现问题。

内部连接池的问题 我也有疑问 我理解是 host 不通 连接池不复用，既然不复用的话 那为什么之前的问题就好了
同时附上我昨天修改之后的代码 https://goplay.space/#L1HS0igSwwc

不知道 MaxIdleConnsPerHost 在 tcp conn 复用中起到怎么样的作用，我看代码发现其作用是用来控制 transport.tryPutIdleConn 方法中是否把 conn 加入连接池，所以我把 MaxIdleConnsPerHost 关了 但是这样的话不就不能复用了吗？
那这样使用同一个 transport 和 client 意义何在？

@SunRunAway 同问

@icexin 感谢你的回复 尝试了你的代码之后暂时没发现报错了，但是有个疑问，transport 内部管理的是 tcp conn，同一个 client 和 transport 可以复用不同的 host 的 conn 吗？