建议handler里得方法增加context参数在第一位

[ayamzh]

这样在中间件里有一些需要和handler中共享的状态，可以放到context中，根据 Go 的最佳实践，也建议将 context.Context 参数放在函数参数列表的第一位。

[hcraM41]

首先，感谢您的issues~ context其实是存在一些争议的，go核心开发者ianlancetaylor专门开了个issue(28342)，记录了当前context的问题； https://github.com/golang/go/issues/28342

尽管有很多的争议，但是在很多场景下，使用context会很方便，所以现在它在go生态圈中比较活跃，包括很多的web应用框架，几乎是标配； 如果我们遇到了以下的场景，是可以考虑使用context的： 1.上下文信息传递，比如处理http请求，在请求处理链路上传递信息； 2.控制子goroutine的运行； 3.超时控制的方法调用； 4.可以取消的方法调用； 通常开发中我们用context来控制子协程的运行会多一点；

关于zinx： 1.目前zinx涉猎的是tcp的框架，一条请求一般会把所有的消息绑在request上， 如果从上下文信息传递的方面考虑出发，这里你也可以理解request其实就是zinx里的context； 2.zinx的业务框架处理模式是worker工作池的模式，后续如果会有控制子协程的调度需求，是可以考虑添加context呢~

[ayamzh]

首先，感谢您的issues~ context其实是存在一些争议的，go核心开发者ianlancetaylor专门开了个issue(28342)，记录了当前context的问题； golang/go#28342

尽管有很多的争议，但是在很多场景下，使用context会很方便，所以现在它在go生态圈中比较活跃，包括很多的web应用框架，几乎是标配； 如果我们遇到了以下的场景，是可以考虑使用context的： 1.上下文信息传递，比如处理http请求，在请求处理链路上传递信息； 2.控制子goroutine的运行； 3.超时控制的方法调用； 4.可以取消的方法调用； 通常开发中我们用context来控制子协程的运行会多一点；

关于zinx： 1.目前zinx涉猎的是tcp的框架，一条请求一般会把所有的消息绑在request上， 如果从上下文信息传递的方面考虑出发，这里你也可以理解request其实就是zinx里的context； 2.zinx的业务框架处理模式是worker工作池的模式，后续如果会有控制子协程的调度需求，是可以考虑添加context呢~

了解，那其实和我们公司框架有点类似，区别是我们公司反过来，是req绑定在ctx里。context作为一个天然的balckboard