context.WithoutCancel 并不存在，正确做法是用 context.Background() 作为根新建 context，再通过 WithTimeout 或 WithCancel 构建独立生命周期。
context.WithoutCancel 的作用和常见误解
context.WithoutCancel 并不是 Go 标准库中提供的函数，它不存在于 context 包里。很多人在搜索“如何创建不继承父 context 取消信号的子 context”时，误以为有这么一个现成函数，结果编译报错：undefined: context.WithoutCancel。
它的实际需求是：父 context 可能已被取消（或将来会取消），但你希望新 context 完全无视这个取消信号，保持活跃，直到你显式控制其生命周期（比如用 context.WithTimeout 或手动调用 cancel()）。
正确做法：用 context.Background() 或 context.TODO() 作为新根，再套一层可取消/超时逻辑
真正可行的方式，是切断与原 context 的取消链路——即不用 context.WithCancel/context.WithTimeout 等以父 context 为参数的构造函数，而是从干净的根 context 出发重新构建。
无序列表说明关键点：
-
context.Background()是所有 context 的顶层根，它永远不会被取消，也没有 deadline 或 value；适合用作新建独立上下文的起点 -
context.TODO()语义上表示“此处本该有 context，但暂时没传入”，行为等同于context.Background()，也可用，但更推荐Background()表明主动选择而非占位 - 如果你需要带超时或手动取消能力，就基于
context.Background()调用context.WithTimeout()或context.WithCancel()，这样新 context 的取消只受自己控制，与上游无关
示例：
// 错误：试图继承已取消的 parent，子 context 也会立即 Done() child := context.WithCancel(parent) // parent.Done() 已关闭 → child.Done() 也已关闭 // 正确：完全脱离 parent 取消链 independent := context.WithTimeout(context.Background(), 5*time.Second) // 即使 parent 被取消，independent 仍会运行满 5 秒（或提前被你调用 cancel()）
为什么不能用 context.WithValue 或自定义 wrapper 来“屏蔽”取消信号
有人尝试写个 wrapper 类型，重写 Done() 方法返回 nil 或新 channel，但这违反 context 设计契约：
- context 的取消传播是树状、不可逆的；一旦父节点取消，所有子节点必须响应，否则会导致 goroutine 泄漏或资源未释放
- 标准库中的
http.Server.Serve、database/sql等都依赖ctx.Done()做清理，绕过它会让这些组件无法感知终止信号 - Go 团队明确反对通过类型嵌套或接口欺骗来“劫持” context 行为，因为这破坏了 context 的可预测性
所以，“不继承取消”不是指隐藏取消信号，而是指**不把父 context 当作取消源**——换根才是正解。
真实场景中容易踩的坑
典型误用发生在 HTTP 中间件或数据库查询封装里：
- 在中间件中接收
req.Context()，直接传给下游 service 调用，却期望某个子操作“忽略请求取消”（比如发一条审计日志），结果日志常因客户端断连而丢失 - 修复方式不是“去掉取消”，而是用
context.WithTimeout(context.Background(), time.Second)新建一个短生命周期 context 专用于日志，确保它不受 HTTP 请求生命周期影响 - 另一个坑是混用
context.WithCancel(parent)和后续对parent的 cancel 调用，误以为子 context 能幸免——只要 parent 被 cancel，所有基于它派生的 context 都会同步关闭，无论是否调用过WithoutCancel（因为这函数根本不存在）
最常被忽略的一点：context 的“不可取消性”必须从源头切断，而不是在中途打补丁。一旦你持有某个非-background 的 context 实例，它的取消命运就已经绑定好了。
