found a struct that contains a context.Context field (containedctx)

[CarlJi]

在 Go 语言中，context.Context 是一个非常常用的类型，用于控制协程的生命周期、传递取消信号、以及管理超时等功能。它的主要作用是跨 API 边界传递上下文信息。根据 Go 官方的建议和最佳实践，context.Context 的使用方式有一些明确的规则，如果违反这些规则，可能导致代码的设计和行为出现问题。

当你看到静态分析工具或代码检查工具（如 revive）报告类似 "found a struct that contains a context.Context field (containedctx)" 的问题时，意味着你在某个结构体中定义了一个 context.Context 字段，而这是不推荐的做法。

为什么不应该在结构体中包含 context.Context 字段？

Go 官方给出了关于 context.Context 的一些最佳实践建议，特别是 不要将 context.Context 作为结构体的字段。这条建议背后的原因可以归结为以下几点：

1. context.Context 是用于请求作用域的，而不是长期存储的：

   • context.Context 设计的初衷是用于控制请求的生命周期。它通常是短期的，绑定到某个操作或请求的生命周期。
   • 如果将 context.Context 存放在结构体中，那么这个结构体可能会长时间存在，而 context.Context 却只能维持较短的生命周期（比如在某一请求结束时就应该被取消）。这种设计会导致上下文的生命周期和结构体的生命周期不一致，可能引发内存泄漏或其他无法预料的错误。

2. context.Context 应当作为参数传递，而不是状态持有者：

   • Go 的最佳实践是将 context.Context 作为函数参数传递给需要它的函数，而不是将它作为结构体的一部分存储。在函数调用链中，context.Context 可以从上层传递到下层，控制整个调用链的生命周期。
   • 通过函数参数传递 context.Context 可以确保上下文的状态（如取消、超时等）在调用链中保持一致性，而将其放入结构体中可能导致上下文状态在不同函数调用之间不一致。

3. 容易导致误用和混乱：

   • 如果 context.Context 被存储在结构体中，多个方法可能会共享同一个上下文。这种设计很容易导致误用，因为调用者可能会在不合适的时间或地方取消上下文，影响其他方法的执行。
   • context.Context 的值是不可变的，且推荐是线程安全的。但将其放入结构体中可能会导致开发者误认为可以在不同的地方直接修改上下文，进而导致逻辑错误。

例子

错误的用法：

type MyStruct struct {
    ctx context.Context // 不推荐
}

func (m *MyStruct) DoSomething() {
    // 使用 m.ctx 进行操作，但这种设计可能导致上下文管理混乱
}

在这个例子中，MyStruct 结构体持有了 context.Context，这违反了 Go 的最佳实践，因为 context.Context 的生命周期可能与 MyStruct 的生命周期不一致。此外，多个方法可能会共享和误用这个 ctx，导致上下文管理混乱。

推荐的做法：

type MyStruct struct {
    // 其他字段
}

func (m *MyStruct) DoSomething(ctx context.Context) {
    // 在需要的地方传递 context.Context，而不是将其作为结构体的字段
}

在推荐的做法中，context.Context 作为 DoSomething 方法的参数被传入，而不是作为结构体字段。这种做法确保了上下文的生命周期与具体的请求或操作绑定在一起，避免了不一致的问题。

总结

静态分析工具（如 revive）报告的 "found a struct that contains a context.Context field (containedctx)" 意味着你在某个结构体中包含了一个 context.Context 字段，这是不推荐的做法。

根本原因在于 context.Context 是一个短期的、用于控制请求生命周期的工具，而结构体通常会有更长的生命周期。将 context.Context 作为函数参数传递，而不是存储在结构体中，可以避免上下文生命周期管理的问题，并且符合 Go 语言最佳实践。