为什么方法的上下文参数不是指针类型？比如下面这段代码：
package main
import (
"context"
"fmt"
"time"
)
func main() {
// 创建根Context
ctx := context.Background()
// 或者使用TODO（当不确定使用哪种Context时）
// ctx := context.TODO()
processRequest(ctx)
}
func processRequest(ctx context.Context) {
// 检查Context是否已取消
select {
case <-ctx.Done():
fmt.Println("Context cancelled:", ctx.Err())
return
default:
fmt.Println("Processing request...")
}
}
要理解为什么 context.Context 作为方法 / 函数参数时不需要指针类型，核心在于 context.Context 的设计本质 —— 它是一个接口类型，且 Go 语言中接口的传参规则、Context 接口的实现特性共同决定了这一点。
一、先明确：Go 中接口的传参规则
Go 中的接口（interface）是一种 “类型抽象”，接口变量本身存储的是 “类型 + 值” 对（动态类型和动态值）。当你将一个实现了接口的对象传递给接口类型的参数时：
- 若底层值是值类型：传递的是值的副本，但接口变量仍能正确指向该副本；
- 若底层值是指针类型：传递的是指针的副本（本质是指向原对象的地址）；
- 无论哪种情况，接口参数的传递成本极低（仅拷贝一个 “类型 + 指针” 的结构体，约 16 字节），且无需通过指针就能访问底层对象的方法。
而 context.Context 本身是一个接口（而非具体类型），定义如下：
type Context interface {
Deadline() (deadline time.Time, ok bool)
Done() <-chan struct{}
Err() error
Value(key any) any
}
因此，将 ctx（接口类型变量）直接传递给函数参数（同样是 context.Context 接口类型），本质是拷贝这个 “类型 + 值” 对，而非拷贝底层的具体实现对象 —— 这也是接口设计的核心优势。
二、Context 接口的实现特性：“不可变 + 链式派生”
Context 的核心设计原则是不可变（immutable） + 链式派生（通过 WithTimeout/WithCancel/WithValue 等方法基于父 Context 创建子 Context）：
- 不可变性：所有 Context 的实现（如
emptyCtx、timerCtx、cancelCtx等）都没有可修改的字段 ——Done()返回的 channel 是只读的，Err()返回的错误是派生时确定的，Value()是只读的键值对。因此，不需要通过指针来修改 Context 本身（也无法修改），传递值（接口副本）完全足够。 - 链式派生的本质是指针：Context 的具体实现（如
timerCtx）本身是结构体 + 指针，例如：
type timerCtx struct {
cancelCtx
timer *time.Timer // 定时器指针
deadline time.Time
}
当你调用 context.WithTimeout 时，返回的 ctx 接口变量中，动态值其实是 *timerCtx（指针类型）。因此，即使传递接口副本，其内部的动态值仍是指向原 timerCtx 对象的指针 —— 这意味着：
- 子 goroutine 中拿到的
ctx接口副本，依然能通过Done()感知到原 Context 的取消 / 超时； - 调用
ctx.Err()能正确获取原 Context 的错误（如context deadline exceeded）。
三、你的示例代码验证
ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
defer cancel()
go func(ctx context.Context) {
<-ctx.Done() // 能感知到原 ctx 的超时
fmt.Println("超时退出：", ctx.Err()) // 正确输出超时错误
}(ctx) // 传递接口副本，内部指向原 *timerCtx
这里传递的 ctx 是接口变量的副本，但副本的动态值是 *timerCtx 指针 —— 因此子 goroutine 能监听原 Context 的 Done() channel，感知超时 / 取消。
四、为什么不建议用 *context.Context？
如果强行将参数定义为 *context.Context（接口的指针），会带来两个问题：
- 毫无必要：接口本身已经能通过内部指针指向具体实现，再套一层指针完全多余；
- 代码冗余且易出错：调用时需要传递
&ctx，且空接口指针（*context.Context(nil)）比空接口（context.Context(nil)）更难处理，容易引发 nil 解引用错误。
总结
context.Context 作为参数不用指针的核心原因：
- 接口特性：接口传参是拷贝 “类型 + 值” 对，成本低，且能指向底层具体实现；
- 设计原则：Context 是不可变的，通过链式派生创建，底层实现本身已是指针类型，接口副本仍能访问原对象；
- 最佳实践：Go 官方（包括标准库）所有接收 Context 的函数，参数都定义为
context.Context（而非指针），这是统一的规范。
简单记：接口类型参数几乎从不需用指针，Context 作为接口自然遵循这一规则。