Go context.WithCancel 不调用 cancel 为什么会泄漏

会。更准确地说，context.WithCancel 返回的 cancel 如果一直不调用，子 context 可能继续挂在父 context 上；如果还有 goroutine 等待它的 Done()，这些 goroutine 也不会因为调用方已经返回而自动结束。它不是“每漏一次就立刻内存暴涨”，但在循环创建、长生命周期父 context 或后台 worker 场景中，确实会变成可观测的资源泄漏。

创建方拥有取消责任：子操作完成、失败或提前退出时都调用 cancel；而 goroutine 是否能结束，还取决于它是否真的监听 ctx.Done()。

为什么不调用 cancel 会让子 context 活得太久

WithCancel(parent) 建立的是一棵取消树。父节点会知道自己的子节点，子节点也持有父节点；调用 cancel 后，子节点的 Done 被关闭，父节点对它的关联被移除，后代也收到取消信号。只要父 context 仍然长存，忘记取消的子节点就可能比一次请求、一次任务需要的时间更久。

因此要区分两个现象：只忘记 cancel，通常先是 context 关联和相关对象延迟释放；如果下游启动的 goroutine 只等 ctx.Done()，它会一直阻塞，才形成典型的 goroutine 泄漏。WithCancel 本身不像 WithTimeout 那样新增一个定时器，但这不代表可以省略取消。

创建后立刻安排 cancel，覆盖所有返回路径

取消责任应该放在创建子 context 的函数里，而不是交给某个不清楚生命周期的下游函数。只要后续代码不需要提前保留它，创建后马上安排 defer cancel()，正常返回、错误返回和中途校验失败都会执行。

func loadProfile(parent context.Context, id string) (Profile, error) {
	// 创建方拥有子 context 的生命周期，先登记兜底清理。
	ctx, cancel := context.WithCancel(parent)
	defer cancel()

	// 下游必须接收同一个 ctx，才能感知上游的取消。
	profile, err := queryProfile(ctx, id)
	if err != nil {
		return Profile{}, err
	}
	return profile, nil
}

这里的 defer 不是为了“等垃圾回收”，而是明确告诉调用链：loadProfile 结束后，子 context 不再有用。若函数把 cancel 返回给调用方，则必须把责任写进接口约定，并确保每个调用方都执行；对请求处理函数来说，局部 defer 往往更不容易漏。

只有 cancel 还不够，worker 必须有退出分支

常见误区是创建了可取消 context，却启动一个没有读取 Done 的 goroutine。这样的 goroutine 不会因 cancel 自动消失。生产代码应让每个长期运行的循环都拥有明确的停止条件，并在输入 channel 关闭时结束。

func startWorker(parent context.Context, jobs 

调用方要在任务完成、失败或被替换时调用返回的函数；如果 worker 只是请求级 goroutine，则可以直接把请求 context 传入，并由请求边界负责取消。不要用 context.Background() 在下游重新开一棵树，否则上游的取消信号无法传到 worker。

用这张清单判断是不是 context 泄漏

排查时可以先用 goroutine profile 看数量是否随请求增长，再沿 goroutine 堆栈找到阻塞 channel 或等待条件；同时检查创建子 context 的代码路径。调用 cancel 只能解除 context 关联并广播取消，不能替代 rows.Close()、文件关闭或业务队列确认。

相关问题

WithCancel 不调用 cancel 一定会内存泄漏吗？

不一定立刻表现为堆内存持续上升，但它会让子 context 及其后代延迟结束；父 context 越长寿、创建次数越多，风险越明显。

父 context 结束后还需要调用 cancel 吗？

仍建议调用。父节点取消会传播到子节点，但创建方保留 defer cancel() 能覆盖父节点未取消、提前返回和未来改造后的路径。

cancel 能关闭业务 channel 吗？

不能。它只发送 context 的取消信号；业务 channel、数据库结果集和文件仍由各自的所有者关闭。