先来理解一下上下文context。

1.什么是程序上下文context

与计算机体系中的相关上下文概念类似，比如进程上下文。

程序上下文，context，程序中共享的信息，保存着程序运行或交互中需要保持或传递的信息。比如所处环境，当前运行状态。

context就是一些变量的集合，简单理解为方法中的参数(或类中的属性)，跟普通要传递的参数对象没什么区别。

context的有时是为了参数传递，有时是为了信息追踪，有时是为了获得控制权，比如超时等待控制。

2. 程序上下文件的生命周期

借用servlet的生命周期：application/request/session/page，或者变量的作用域：全局变量，局部变量，参数传递。

context也是这样，它有一定的生命周期或作用域。

网页请求中的session，理解为一种context，也是合适不过，登录控制中，需要知道用户是否登录，用户是谁，用于保持登录状态，并在不同的请求中传递状态。

不过我们一般说程序上下文，不是全局性的，缘起缘灭，总是在一个一次性事件当中，从产生直到消亡，共享和传递信息，用完即丢。

进程产生，有进程上下文，用于进程切换和恢复，进程结束，上下文也消亡了。

http一次请求，把请求信息作为上下文参数，一直传递下去，请求结束，上下文也消亡了。

以上是对程序中上下文的理解。

我们在开发golang程序时，喜欢定义一个struct，然后定义一个全局的变量，通过一个变量静态地调用方法。这是省了每次都要NEW一个对象，直接可以调用。参考java中的SSH的做法，但是有其形无其实。当然，go项目一般不会这么干吧。

package api


var (
	appService services.AppService
)
type ExampleController struct {
    ApiController
}


func (this *ExampleController) Info() {
	app,err := appService.GetApp(1)
	if err != nil {
		this.RenderJson(err)
	}
	this.RenderDataOk(app)
}

一开始是觉得简化了许多，也就一直这样开发下来。但最近就发现，服务里面没办法感知上层信息，比如调用者信息，分布式追踪信息，其实就是上下文信息。难道要把这些信息一一传进去？信息传是要传的了，只是要怎么传呢？

首先是想到可以每次实例化对象，把上下文作为属性，设进去，或者参考java的方法，可以直接注入进去。但是我们框架可没有spring的功能，如果要实现就得修改一下框架了。

不过搜一下，golang的上下文机制就出现在眼前，已经在1.7时成为标准库。结合最近看的etcdv3、grpc的开源实现，就已经关注到有个ctx的东西如影随形，这时才恍然大悟。这不就是我们需要的上下文吗？只是，每次都要作为第一个参数传递（使用原则一），也够辛苦的了。好吧，既然是这样的风格，那我们也学好了。

在新的项目中，打算使用这样方式传递。如果作为类的属性，能过构造或set方法，也是蛮好的，这就根据实际情况吧。

我们使用beego，调用时 ，会使用一个方法把beego的context转换到标准库context，不过我想，直接用beego的context也没多大问题。