WithoutCancel 怎样创建不继承取消信号的收尾任务

HTTP 请求被取消后，日志、审计和指标上报有时还需要几百毫秒才能收尾。做法不是把 context.Background() 硬塞进 goroutine，而是先用 context.WithoutCancel(parent) 切断父 context 的取消链，再用 context.WithTimeout 给收尾动作设置自己的上限。这样既能保留请求范围内的值，又不会让收尾任务无限期运行。

官方地址：https://pkg.go.dev/context#WithoutCancel

先判断：这个动作是否值得脱离请求

适合脱离取消链的通常是写审计事件、落盘操作、发送内部指标，特点是动作短、输入可以复制、失败可以记录。读取请求体、继续操作已经关闭的连接，或者启动一个没有结束条件的后台循环，都不适合用 WithoutCancel。它只是改变取消传播，不是把请求生命周期变成长任务许可证。

我会先把需要的字段做成快照，再把快照交给收尾函数。这样请求返回后，收尾逻辑不会偷偷引用可能已经被复用的可变对象。

WithoutCancel 只切断取消，不负责给任务续命

官方定义有几个容易漏掉的细节：返回的 context 仍然指向 parent，所以 Value 查找还能沿父链进行；但它不会因 parent 取消而取消，Deadline 没有结果，Err 返回 nil，Done() 为 nil，context.Cause 也返回 nil。

因此，下面这段代码中的 select 不会因为原请求取消而结束。没有独立超时的话，写入函数卡住就可能一直占着 goroutine。

package main

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

func cleanupContext(parent context.Context) context.Context {
    // 保留 request_id 等请求范围值，但切断 parent 的取消传播。
    detached := context.WithoutCancel(parent)
    fmt.Println(detached.Err() == nil, detached.Done() == nil)
    return detached
}

收尾任务要再包一层独立超时

生产代码更适合把两层 context 写得很明显：第一层负责“不要跟着请求一起取消”，第二层负责“这个动作最多运行多久”。WithTimeout 的父级应该是 detached，而不是原始 request context。

func enqueueAudit(parent context.Context, event AuditEvent) 

这里的 AuditEvent 应该是值类型或已经完成深拷贝的结构；如果内部含有 map、slice、指针，仍需按业务字段复制。调用方可以等待 done，也可以交给已有的收尾调度器，但要明确谁负责记录超时。

参数和边界怎么选

一个实际判断标准是：如果任务的输入能在启动前冻结、失败能被记录、最长耗时能预估，它通常适合这种模式；如果任务依赖请求上下文中的实时权限、连接或取消原因，就应让它跟随原 context 结束。

常见问题

WithoutCancel 会保留父 context 的 deadline 吗？

不会。返回 context 没有 deadline，调用 Deadline 得不到有效截止时间，所以必须自行使用 WithTimeout 或 WithDeadline。

为什么不直接用 context.Background？

Background 没有父链值，像 request_id 这类请求范围信息会丢失。WithoutCancel 适合“保留值、切断取消”的场景。

收尾任务一定要启动 goroutine 吗？

不一定。如果请求处理函数可以在返回前同步完成短操作，就不必异步；只有需要与响应返回并行时才启动 goroutine，并配合独立超时和完成回路。

记住一句话：WithoutCancel 解决的是取消传播，WithTimeout 解决的是任务寿命。两者叠加，才是可控的 Go 收尾任务方案。