后端开发中，问题分析通常是请求级别的，如果能通过一个唯一的请求号对日志进行过滤，能对分析问题带来不少的便捷。我们的项目中也希望在请求相关的日志中，嵌入请求号。
Golang在http.Request中提供了一个Context用于存储kv对，我们可以通过这个来存储请求相关的数据。在请求入口，我们把唯一的requstID存储到context中，在后续需要调用的地方把值取出来打印。如果日志是在controller中打印，这个很好处理，http.Request是作为入参的。但如果是在更底层呢？比如说是在model甚至是一些工具类中。我们当然可以给每个方法都提供一个参数，由调用方把context一层一层传下来，但这种方式明显不够优雅。
那么Golang有没有提供一个静态方案获取当前context呢？答案是否定的。有没有提供类似ThreadLocal这样的机制获取Goroutine的上下文呢？答案也是否定的。
理由是Andrew Gerrand认为通过线程上下文这种方式传参“带来的问题比解决的问题多”。
We wouldn't even be having this discussion if thread local storage wasn't useful. But every feature comes at a cost, and in my opinion the cost of threadlocals far outweighs their benefits. They're just not a good fit for Go.
官方不但不提供这样的方法，还不遗余力的让第三方也无法提供--Golang不提供任何可以让你获知当前GoroutineID的方法。
不过，哪里有压迫，哪里就有反抗。还是有第三方的库做了类似的功能。
首先是一个库做了一个获取当前所在GoRoutine的方法，https://github.com/bradfitz/http2/blob/dc0c5c000ec33e263612939744d51a3b68b9cece/gotrack.go
原理是利用了runtime.Stack的字符串格式
可以看到在Stack的开头打印了一个类似于goroutineID的东西。有了goroutineID，GoRoutine的local storage实现方式也就是顺理成章了，只要把context存放在以goroutineID为key的map中即可。
另外有一个库jtolds/gls，它的实现方式就奇特多了。同在runtime包下面，有一个Callers方法，可以获取当前调用栈的pc列表。这个gls库就是利用这个Callers方法。
gls库预先定义了16个可嵌套的空方法，调用方需要用到GoRoutineLocal功能时，需要把用到这个功能的根方法作为参数传入到gls中，gls按顺序生成未被使用的GoRoutineID，然后把GoRoutineID种入到调用栈中。具体的方法就是利用前面所述的16个空方法进行编码，每个方法使用与否分别代表一个bit的0或1，最终通过这16个方法编码成16个bit的GoRoutineID。解码时，只需通过Callers方法获取pc列表，与16个方法的pc进行匹配即可把GoRoutineID解码出来。
第一种方法利用的是golang打印格式，虽说这种打印格式不太可能会在golang的未来版本发生改变，但毕竟恶心；第二种方法脑回路清奇，似乎也没有什么限制，但要用在生产上的话，还是算了吧。
