Go context.WithoutCancel 怎么保留收尾任务：请求取消与后台清理的边界

订单接口已经返回 499，后台却还要把审计记录写完整，这是 Go 服务里很容易被误判的一类取消问题。直接把请求的 ctx 传给收尾函数，客户端一断开，审计写入也会跟着停止；把任务丢给 context.Background() 又会丢掉请求中的租户等值。Go 1.21 提供的 context.WithoutCancel 正好切开这两个需求：保留 Value，不再继承取消信号和截止时间。

收尾任务可以使用 context.WithoutCancel(ctx)，但不要直接把它当作永久后台上下文；再套一层独立的 context.WithTimeout，才能限制清理时间并保证退出。

先把两条时间线分开：请求取消与收尾任务

假设 POST /orders 已经写入订单，但在返回前还要追加一条 order_audit 记录。用户切到后台，网关关闭连接，入口上下文的 Done 被关闭。订单主流程应该尽快停止等待；审计写入则通常只需要几百毫秒，值得在受控时间内完成。

这里的边界不是“所有后台任务都不许取消”，而是把责任拆成两条链：请求取消结束调用方的等待，收尾任务用自己的时限完成必要落盘。图中四个节点对应这条调用链，读图时重点看取消信号在哪里被切断。

用 WithoutCancel 保留请求值，但切断取消传播

WithoutCancel 返回一个指向父上下文的派生上下文。它仍然能读取 tenantID 这类值，却不会因为父上下文取消而关闭自己的 Done。这比直接使用 context.Background() 更适合需要请求元数据的收尾逻辑。

package audit

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

type tenantKey struct{}

func writeAudit(ctx context.Context, orderID string) error {
    tenantID, ok := ctx.Value(tenantKey{}).(string)
    if !ok || tenantID == "" {
        return fmt.Errorf("missing tenant id")
    }
    // 这里替换成真实的 INSERT 或消息写入。
    fmt.Printf("audit order=%s tenant=%s\\n", orderID, tenantID)
    return nil
}

func finishOrder(reqCtx context.Context, orderID string) error {
    detached := context.WithoutCancel(reqCtx)
    cleanupCtx, cancel := context.WithTimeout(detached, 800*time.Millisecond)
    defer cancel()
    return writeAudit(cleanupCtx, orderID)
}

注意 WithoutCancel 只是切断父级取消和 deadline，不会替收尾操作生成一个新的截止时间。因此示例紧接着使用 WithTimeout，把最多 800 毫秒的资源边界写在收尾函数内部。

用可核对的结果判断是否真的收尾完成

把收尾动作放进 goroutine 后，主处理函数要明确它是否需要等待。如果业务要求“响应前必须记审计”，就同步调用 finishOrder；如果允许响应先返回，则异步执行，但要有任务队列、日志和失败重试，而不是裸起一个无限期 goroutine。

func handleOrder(ctx context.Context, orderID string) error {
    if err := saveOrder(ctx, orderID); err != nil {
        return err
    }

    if err := finishOrder(ctx, orderID); err != nil {
        return fmt.Errorf("audit cleanup: %w", err)
    }
    return nil
}

压测时至少记录三项：请求取消比例、收尾超时次数、order_audit 实际写入数。第二张图把“独立超时”与“清理完成”放在同一条验证路径上，避免只看到主请求返回成功就误判后台工作已经落盘。

三个容易踩到的边界

不要用 Background 代替所有上下文

context.Background() 既没有请求值，也没有任何截止时间。它适合作为根上下文，不适合作为每个请求收尾的默认替代品。

不要把 WithoutCancel 当成永久运行许可

只要外层没有新的超时，数据库卡住或下游网络异常就可能让任务长期占用资源。用 WithTimeout 或队列消费者的生命周期控制它。

不要忽略值的安全边界

上下文值适合传递请求范围的标识，不适合塞入大对象、可变共享状态或必须实时变化的配置。收尾逻辑即使脱离取消，也仍需遵守数据权限和幂等约束。

常见问题

WithoutCancel 会保留原来的 deadline 吗？

不会。它不会继承父上下文的 deadline 和取消错误；需要限制时间时，应在它之上重新创建带超时的上下文。

收尾任务一定要用 WithoutCancel 吗？

不一定。如果任务必须随请求立即停止，继续使用原始 ctx 更准确。只有在业务明确允许短暂收尾、并且有独立生命周期时才使用它。

怎样证明审计确实写成功了？

让写入函数返回明确错误，并在数据库或消息系统侧按订单号核对记录；不要把 goroutine 启动成功当成业务完成。

把收尾边界写进代码评审清单

评审这类代码时，沿着“请求取消 -> 收尾任务 -> WithoutCancel -> 清理完成”逐项核对：是否确实需要保留请求值，是否设置了独立超时，是否有幂等键，是否记录失败，是否能从 order_audit 反查结果。能回答这五个问题，才算把取消语义和资源边界同时交代清楚。