We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
这样在中间件里有一些需要和handler中共享的状态,可以放到context中,根据 Go 的最佳实践,也建议将 context.Context 参数放在函数参数列表的第一位。
The text was updated successfully, but these errors were encountered:
首先,感谢您的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呢~
Sorry, something went wrong.
首先,感谢您的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
No branches or pull requests
这样在中间件里有一些需要和handler中共享的状态,可以放到context中,根据 Go 的最佳实践,也建议将 context.Context 参数放在函数参数列表的第一位。
The text was updated successfully, but these errors were encountered: