context.context 是值传递但不拷贝底层数据，因其是轻量接口句柄，仅复制类型信息和指针；底层 deadline、done channel、value 链表共享且不可变，with 系列函数返回新实例保证安全。
为什么 context.Context 是值传递，但实际不拷贝底层数据？
因为 context.Context 是接口类型，它本身是小而轻量的“句柄”，不是大结构体。每次传参时复制的只是这个接口的头部（含类型信息和数据指针），底层存储的 deadline、done channel、value 链表等仍是共享的——但**不可变封装保证了安全**。
-
context.WithValue、context.WithTimeout等操作都返回新接口实例，旧 context 完全不受影响 - 底层数据结构（如
valueCtx、cancelCtx）内部字段多为指针或 channel，值传递接口不会触发深度拷贝 - 你不能通过
ctx.Value(key)修改原 context 的值——它只读；所谓“传递”，本质是链式引用+不可变构造
context.Context 作为参数时，传指针会出什么问题？
传 *context.Context 不仅没意义，还会破坏设计契约，引发并发和生命周期混乱。
- Go 标准库所有 context 函数（如
context.WithCancel）都接收并返回context.Context接口值，不是指针——强行取地址会导致类型不匹配 - 若某函数接收
*context.Context，调用方必须确保该指针在整个生命周期内有效，极易出现 dangling pointer 或重复 cancel - 多个 goroutine 持有同一
*context.Context时，无法防止误调用cancel()，违背“谁创建，谁 cancel”原则
哪些场景下你会误以为需要传指针？
常见错觉来自对“可变性”的误解，比如想在函数里修改 context 携带的值，或想复用 cancel 函数。
- 想“更新” context 中的值？→ 错。应调用
context.WithValue得到新 context，原 context 仍可用 - 想在子 goroutine 里调用 cancel？→ 危险。cancel 函数必须由创建者持有并控制，子 goroutine 只能监听
ctx.Done() - 想把 context 存进 struct 做长期持有？→ 谨慎。除非该 struct 生命周期明确短于 context，否则易造成内存泄漏（如闭包捕获了 long-lived ctx）
函数签名里要不要总把 ctx context.Context 放第一位？
不要。Go 官方明确反对硬编码 ctx 为首位参数，它不是装饰，而是有明确语义的协作信号。
立即学习“go语言免费学习笔记（深入）”；
- 纯计算函数（如
strings.ToUpper、json.Marshal）完全不需要ctx - I/O 密集型函数（如
http.Client.Do、sql.DB.Query）才需接收，并向下传递派生出的新 context - 如果函数既不响应取消、也不设超时、也不传元数据，加
ctx参数只会让测试变重、调用方困惑、IDE 跳转失效
context.WithValue 就会变成隐藏的类型黑洞。 
