Go context cause 只能在取消后读取时为什么提前取不到

如果你在创建 context 后马上调用 context.Cause(ctx)，拿到 nil 是正常的。cause 不是预先挂在 context 上的配置值，而是取消发生时记录的原因；只有观察到 ctx.Done() 已关闭，或者确认取消函数已经执行后，读取它才有意义。

context.Cause 负责解释“为什么取消”，ctx.Err 负责告诉调用方“已经因取消还是 deadline 结束”；在取消之前，Cause 必然是 nil。

为什么刚创建的 context 没有 cause

context.Cause 的语义是读取已经发生的取消原因，而不是读取 WithCancelCause 的参数。下面的代码在取消前打印的是 ，因为此时没有任何取消事件。

package main

import (
	"context"
	"fmt"
)

func main() {
	// 先创建可记录原因的 context，但暂时不触发取消。
	ctx, cancel := context.WithCancelCause(context.Background())
	defer cancel(nil) // 释放关联资源；不会把未发生的原因提前写入。

	fmt.Println(context.Cause(ctx)) // 
}

这也是“提前取不到”的根本原因：context 只携带取消信号，cause 要等取消路径真正落地后才确定。若代码要读取 cause，应把读取动作放在取消函数之后，或放在等待 的分支中。

手动取消时，Err 和 Cause 为什么不同

使用 WithCancelCause 时，取消函数接收一个错误。这个错误是给诊断和下游映射使用的；ctx.Err() 仍然保持标准的取消分类，便于调用方用 errors.Is 判断。

package main

import (
	"context"
	"errors"
	"fmt"
)

func main() {
	errUpstream := errors.New("上游配置已变更")
	ctx, cancel := context.WithCancelCause(context.Background())
	cancel(errUpstream) // 取消发生后，cause 才被记录。

	fmt.Println(ctx.Err() == context.Canceled) // true
	fmt.Println(errors.Is(context.Cause(ctx), errUpstream)) // true
}

生产代码通常先用 ctx.Err() 判断控制流，再用 context.Cause(ctx) 补充日志、指标或业务错误。不要把 Cause 当成“取消状态”的替代品，也不要在 context 仍可用时把 nil 当成异常。

deadline 到期前读取，为什么仍然是 nil

WithTimeoutCause 只有在 timeout 真正到期时才会把预设错误写入返回的 context。返回的 CancelFunc 可以提前释放资源，但手动调用它不会把预设的 timeout cause 当作已经发生。

package main

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

func main() {
	timeoutCause := errors.New("依赖服务响应超时")
	ctx, cancel := context.WithTimeoutCause(context.Background(), 20*time.Millisecond, timeoutCause)
	defer cancel() // 只负责清理；读取结果要放在 Done 之后。

	

如果把上例中的 删除，读取结果就可能是 nil；如果改成先调用 cancel() 再读取，Cause(ctx) 通常会回到 context.Canceled，而不是预设的 timeoutCause。这两个行为都符合 API 约定。

把 cause 交给下游时要抓住首次取消

父子 context 都可能被取消，但每个 context 的首次取消决定自己的 cause。下游函数应在收到 ctx.Done() 后读取原因，并把它包装或映射成调用方能识别的错误；不要在函数入口提前读取。

func load(ctx context.Context) error {
	// 先让实际工作响应取消，再在取消分支读取稳定的原因。
	select {
	case 

排查父子链路时，重点看“谁先取消”：父 context 先取消，子 context 会继承父原因；子 context 先取消，则子可以保留自己的原因。只要把 Err 作为状态、把 Cause 作为解释，并在 Done 后读取，错误映射就不会因为时序过早而丢失信息。

相关问题

context.Cause(ctx) 什么时候一定不是 nil？

当该 context 或其父级已经完成取消，并且你在取消事件之后读取时，Cause 才会返回非 nil 错误；没有自定义 cause 时，它会返回与 ctx.Err() 相同的取消错误。

WithTimeoutCause 的 cancel 要不要调用？

要调用。它用于释放定时器和派生 context 资源，只是不要把手动 cancel() 误认为 timeout 已发生；真正的超时原因要在 后再判断。

参考：Go context 包文档、Go 标准库 context 源码。