近日某公众号连推2篇关于context的文章，图文不符的错误多处，也不适合我理解，因此查看官方文档后总结一篇笔记。

context package - context - pkg.go.dev 

type Context interface {
	Deadline() (deadline time.Time, ok bool)
	Done() <-chan struct{}
	Err() error
	Value(key interface{}) interface{}
}

本文不会直接讲述context的设计初衷和由来，也不会直接讲述context相比于其他并发控制方式的优劣。

本文旨在通过解析context包官方文档和示例来探明context的使用方式，从而反推其使用场景。

这里先贴一下官网文档的Overview部分的简单直译。这部分内容描述了context包的使用方式、主要结构、使用场景，当写完整篇笔记后再来印证可以更深刻理解。

一、Overview部分直译，为便于理解有删减，完整内容查看官网链接:

context包提供了Context类型，这种类型可以承载deadlines、取消信号等可以在API边界和进程之间传递消息的对象。

向server发出请求时应当创建一个context，server处理呼叫应当接收context。整个调用链中context应当作为参数被处理函数传递。这些context可以是也最好是WithCancel, WithDeadline, WithTimeout 或者 WithValue这些衍生出来的child context。当一个Context被取消时，他的child context也会取消。

WithCancel, WithDeadline, WithTimeout这几个函数接收一个父Context对象，返回子Context对象和一个CancelFunc。当调用对应的CancelFunc时，对应的子Context对象就会被取消。调用CancelFunc失败则child context就会泄露直到父context被取消或者自身超时。

使用context的程序应当遵循以下规则，以便允许静态分析工具可以获知context的传播链路：

1. 不要在struct type中存储context，而应当将其作为函数的参数进行传递，即想要使用context时应该给函数额外加一个ctx的参数。

func DoSomething(ctx context.Context, arg Arg) error {
	// ... use ctx ...
}

2. 永远不要传递nil context，如果你不确定该使用哪种context，那么可以先传个context.TODO替代。

3. Values不应当用作业务参数的传递(虽然这么做确实可以)，而应当用来在APIs、processes之间传递消息。

4. 多个goroutine函数可以共用Context, context是并发安全的。

可以通过此地址查看示例：Go Concurrency Patterns: Context - go.dev，获知server是如何使用context传递消息的。

二、context包提供了四种child context使用示例：

Context接口并不需要我们自己实现，context包已经提供了2个函数(context.Background()和context.TODO())来返回空Context类型，并提供了4个With开头函数来生成具有特定功能的child Context。

• WithCancel

func WithCancel(parent Context) (ctx Context, cancel CancelFunc)

 WithCancel返回一个child Context ctx，相比于输入的parent，其重写了Done()，实现的功能是：当CancelFunc被调用或parent的Done被写入时，ctx的Done channel会被写入(struct{}{}的空消息)，使用ctx的goroutine就可以通过读取ctx.Done()来获知取消信号了。

package main

import (
	"context"
	"fmt"
)

func main() {
    // gen是一个函数，用于不断的返回整数数字，因为是返回的是只读的unbuffered channel，因此只有当返回值被消费时才会继续返回下一个
	gen := func(ctx context.Context) <-chan int {
		dst := make(chan int)
		n := 1
		go func() {
            // 在gen内部，通过for select不断的检查ctx.Done()信息来确定自己是否需要return，未接收到ctx.Done()消息时就返回数字等待被消费
			for {
				select {
				case <-ctx.Done():
					return // 当从ctx.Done()接收到消息时return函数，防止泄露
				case dst <- n:
					n++
				}
			}
		}()
		return dst
	}
	// 在gen外部使用WithCancel创建一个ctx，可以看到其parent是context.Background()，context.Background()返回一个非nil的空Context
	ctx, cancel := context.WithCancel(context.Background())
	defer cancel() // 当主函数退出时执行cancel函数，此时ctx.Done() channel就会被写入，从而使gen退出

    // 主函数遍历gen()的输出，当n=5时break循环，break之后defer cancel()触发，之后上述case <-ctx.Done():被触发从而退出gen函数
	for n := range gen(ctx) {
		fmt.Println(n)
		if n == 5 {
			break
		}
	}
    // 试想下如果没有context会怎样: 当main函数for n := range gen(ctx) break之后，gen()依然会无限循环导致goroutine泄露(当然在本例中并不会，因为main函数执行完之后整个进程就退出了)

•  WithDeadline

func WithDeadline(parent Context, d time.Time) (Context, CancelFunc)

WithDeadline返回一个child Context ctx，相比于输入的parent，其deadline不晚于指定的d时刻。如果parent的deadline比d更早，那么按parent的deadline来算。

什么情况下ctx的Done channel会有消息：1. 当到达deadline时刻 2.CancelFunc被调用 3.parent的Done channel被写入。

package main

import (
	"context"
	"fmt"
	"time"
)

const shortDuration = 1 * time.Millisecond  

func main() {
	d := time.Now().Add(shortDuration) // 定义一个基于当前时间1ms后的时刻：d
	ctx, cancel := context.WithDeadline(context.Background(), d)  // 将d作为ctx超时的时刻
	defer cancel() // 当main goroutine结束时调用cancel函数

	select {
	case <-time.After(1 * time.Second):
		fmt.Println("overslept")
	case <-ctx.Done():
		fmt.Println(ctx.Err())
	}
	// 检查time.After(1 * time.Second)和ctx.Done()哪个channel有消息，都没消息就阻塞于此一直检查，发现一个有消息就执行对应逻辑然后执行defer cancel()
    // 主函数直到结束才会调用cancel()，time.After(1 * time.Second)时长高达1s，而deadline时刻只有1ms的长度，所以在1ms后ctx.Done()就会因为deadline到达而被写入，因此这个select会在1ms后就直接接收到ctx.Done()消息，然后执行fmt.Println(ctx.Err())，打印出错误：context deadline exceeded。
    // 在这之后继续执行defer cancel()会继续给ctx.Done() channel发消息，那会遇到send on closed channel的panic吗？不会，Done()的返回是幂等的：Successive calls to Done return the same value.。
    // 既然ctx的Done()会因为deadline到达而被提前写入消息，那还有必要defer cancel()吗？官网的解释是有必要，因为这可以确保ctx及其父context的释放。
}

• WithTimeout

func WithTimeout(parent Context, timeout time.Duration) (Context, CancelFunc)

WithValue相比于之前的3个With开头的函数有区别，他不会返回CancelFunc函数，可以为Context.Value传值。

但是官网明确说明WithValue的key不应该是字符串或任何其他内置类型，以免与context包自用的产生冲突。应当传递业务自定义类型。直接示例之：

package main

import (
	"context"
	"fmt"
)

func main() {
	type favContextKey string  // 自定义一个string的类型：favContextKey

    // 定义函数f，接收ctx和k参数
	f := func(ctx context.Context, k favContextKey) {
        // 获取ctx中存储的key-value pair，如果匹配到了输入参数k对应的值，则把值存入v中并打印
		if v := ctx.Value(k); v != nil {
			fmt.Println("found value:", v)
			return
		}
        // 如果在ctx中未匹配到k对应的value，那么打印未找到信息
		fmt.Println("key not found:", k)
	}

	k := favContextKey("language")
	ctx := context.WithValue(context.Background(), k, "Go")
    // WithValue返回的ctx存储了一个key-value pair,其key为k，value为Go

	f(ctx, k)
	f(ctx, favContextKey("color"))
}

三、总结：

一般来说当一个goroutine启动之后我们就很难控制他的运行了，除非预先定义了一个channel，然后在goroutine内部不断的检查channel的消息来决定后继运行逻辑。

基于此逻辑我们来总结context的使用：

通过上述3个示例，我们可以看到整个context包其实就是围绕Context.Done()这个channel来做文章的。无论是CancelFunc还是Deadline(),Err()，其目的都是辅助Done()，目的就是当满足某些条件时给Done channel传递消息，在goroutine内部则使用select检查ctx.Done()是否有消息来决定下一步的执行逻辑。

context包提供了一个更人性化的channel定义方式，免了开发者自定义各种通信channel的烦恼。

与sync.WaitGroup的区别何在？

很明显的wg用于等到本组内的goroutine自然终结，而context提供了主动终结goroutine的能力，虽然这种能力是建立在需要goroutine内部检查ctx相关状态的基础上的。

最后WithValue的使用与其他几个有很大区别，看起来更加的灵活，可以为goroutine传递更丰富的消息，有待挖掘补充。