Golang Go语言中大家写服务端代码时，是喜欢一个请求一个 goroutine 到底，还是喜欢在一个请求处理 goroutine 里再开其他的 goroutine 呢？
Golang Go语言中大家写服务端代码时，是喜欢一个请求一个 goroutine 到底，还是喜欢在一个请求处理 goroutine 里再开其他的 goroutine 呢？
如果是后一种情况，那么一般在什么地方开新的 goroutine 呢？如果能说一下原因最好了。
在需要等待 io 的地方 最小化 一个 goroutine
更多关于Golang Go语言中大家写服务端代码时，是喜欢一个请求一个 goroutine 到底，还是喜欢在一个请求处理 goroutine 里再开其他的 goroutine 呢？的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html
基于业务,理论上你都在当前开启了一个 goruntine 了. 那就你认为内部的东西是可以异步的. 具体这个异步里面要不要再写 goruntine ,还是要看你的业务能不能 异步, 如果只能同步操作,就不要开启. 如果能异步那就开启 goruntine.
如楼上说的, 基于业务
一般是一个 goruntine 到底，
因为虽然 goruntine、chan 成本低，但是也是有成本，没必要多开一个浪费资源。
但是一些特殊情况下会单独开个 goruntine ，
例如客户一个连接发出多个请求，其中部分请求类型依赖外部服务并且可能高耗时。
在客户端可以接受乱序回应的情况下，会使用新 goruntine 处理，根据不用情况，可能考虑提供线程池等方式处理请求。
给 blog 开发一个接口，根据文章 id，查询文章内容及评论。
初级后端开发：根据 id 查询文章内容，根据 id 查询评论
传统后端开发：根据 id 组成 join 查询语句，把查询丢给 db 处理
现代后端开发：根据 id 同时查询文章内容和评论，组合并返回
在Golang中编写服务端代码时，关于是否应该为每个请求单独使用一个goroutine，或者在处理请求的goroutine中再创建其他goroutine，这取决于具体的应用场景和需求。
使用一个请求一个goroutine的方式，可以简化并发控制，因为每个请求的处理都是独立的，不需要担心多个goroutine之间的同步问题。这种方式适合处理相对简单、独立的请求，能够充分利用Goroutine的轻量级特性，提高并发性能。
然而，在某些情况下，一个请求可能需要执行多个并行的任务。这时，在处理请求的goroutine中再创建其他goroutine就显得非常必要。通过使用sync.WaitGroup或其他同步机制，可以确保所有并行任务都完成后，再返回响应。这种方式能够更灵活地处理复杂的请求，提高系统的吞吐量和响应速度。
但需要注意的是，过度使用goroutine可能会导致上下文切换频繁，增加CPU开销。因此，在设计时应该权衡并发性能和资源消耗，根据实际需求来决定是否需要在处理请求的goroutine中再创建其他goroutine。
总的来说，选择哪种方式应该基于具体的业务逻辑和性能需求。在编写服务端代码时，应该注重代码的可读性和可维护性，同时充分利用Goroutine和Go语言的并发特性来提高系统的性能和响应速度。
