context 标准库的解决思路是：在整个树形逻辑链条中，用上下文控制器 Context，实现每个节点的信息传递和共享。
在 context 库的官方文档中有这么一句话：Do not store Contexts inside a struct type;instead, pass a Context explicitly to each function that needs it.The Context should be the first parameter.大意是说建议我们设计函数的时候，将 Context 作为函数的第一个参数。你能理解官方为什么如此建议，有哪些好处？可以结合你的工作经验，说说自己的看法。
context作为第一个参数在实际工作中是非常有用的一个实践。不管我们是设计一个函数，或者设计一个结构体的方法，或者服务的时候，我们一旦养成了将第一个参数作为context的习惯，那么这个context在相互调用的时候，就会传递下去。这里会带来几个好处：
1 链路通用内容传递。context中是可以通过WithValue方法将某些字段封装在context里面，并且传递的。最常见的字段是traceId, spanId。而在日志中带上这些ID，再将日志收集起来，我们就能进行分析了。这也是我们现在比较流行的全链路分析的原理。
2 链路统一设置超时。我们在定义一个服务的时候，将第一个参数固定设置为context，则可以通过这个context进行超时设置，而这个超时设置，是由上游调用方进行设置，这样就形成了一个统一的超时设置机制。比如A设置了5s超时，自己使用了1s，传递到下游B服务的时候，设置B的context超时时长为4s。这样全链路超时传递下去，就能保持统一设置了。
是的，请求控制和请求实现混在一起的情况，后面引入middleware会改掉的。
PS:其实在 Golang 的设计中，每个 Goroutine 都是独立存在的，父 Goroutine 一旦使用 Go 关键字开启了一个子 Goroutine，父子 Goroutine 就是平等存在的，他们互相不能干扰。而在异常面前，所有 Goroutine 的异常都需要自己管理，不会存在父 Goroutine 捕获子 Goroutine 异常的操作。所以切记：在 Golang 中，每个 Goroutine 创建的时候，我们要使用 defer 和 recover 关键字为当前 Goroutine 捕获 panic 异常，并进行处理，否则，任意一处 panic 就会导致整个进程崩溃！
