深夜失眠修改下答案，想说说题主说的只要控制gorountine数量的问题，我觉得就像sync.Pool一样，Pool中的数据在每次GC的时候都会清掉，所以不能用在一些需要保持连接的场景下，但是存在即合理，sync.Pool就是个临时对象池，可以减轻程序频繁创建对象的消耗，以减轻垃圾回收的压力，gorountine是不是也是一样呢，虽然起一个协程的开销很小，但是在极限情况下，合理复用总是没错的，这事儿还是得结合具体场景来选择，简单限制数量，开发起来快速，彻底池化，可以压榨极限性能。
可能有考虑不周的地方，只是晚上睡不着的一点思考
==========================
原回答:
先明确一些概念:
goroutine是如何调度的，这个需要去了解一下协程的 G-P-M 调度模型，网上已经有太多了，我就不多说了，官方给出的链接:
贴一个中文的比较易懂的链接吧
goroutinegoroutinegoroutineGo Schedulergorountine下面来说说这个问题, Golang开发需要协程池么？
goroutinenet/httpServergoroutinegoroutinegorountineDDOSgoroutinegoroutine(歪一下，GC这事儿，可以看看这个)
这个时候！首先要做一些简单的，比如漏斗限流，限制客户端对某一行为的频率等等...
如果加上协程池会不会更好呢？
goroutine使用协程池将让多余的请求进入排队状态，等待池中有空闲协程的时候来处理，这是模拟的I/O多路复用机制，贴一个原理:
这样就可以通过控制协程池的大小，来控制内存的消耗，让其在极端状态下，也尽可能的保证服务的可用性。
代码的话其他答案里写了有开源的,我就不写啦~
点个赞再走呗～