Go context.Cause 资源没有释放为什么

context.Cause 只是读取取消原因，不会发出取消信号，也不会关闭文件或等待协程退出。日志已经打印出原因而资源仍被占用时，应分别检查：创建者是否调用取消函数、工作协程的阻塞点是否支持退出、资源所有者是否执行 Close，以及调用方是否等到了清理完成。

官方文档：https://pkg.go.dev/context

先分清取消原因与清理责任

假设一个导出任务已经收到“用户停止导出”的错误原因，但输出文件仍然被占用。读取错误原因只能说明上下文的取消状态，不能证明导出协程已离开写入函数，更不能证明它的 defer 已执行。排查应沿着实际占用者查，而不是反复读取 Cause。

用最小配方保留 cancel

需要自定义停止原因时，可以在任务拥有者处创建带原因的上下文，并保留返回的取消函数。以下片段放在任务函数内部，work 代表接收该上下文的业务函数。

// 任务创建者保留取消能力，正常返回也执行收尾取消
ctx, cancel := context.WithCancelCause(parent)
defer cancel(nil)

// work 必须自行响应取消并释放它拥有的资源
err := work(ctx)
if err != nil {
    cancel(err)
}
return err

这里的 defer 用于覆盖正常返回及错误返回路径，不是替业务函数关闭资源。若 work 内启动了后台协程，work 是否等待它们结束必须有明确约定。更不能把 cancel 放在一个刚启动协程就返回的辅助函数中：这样的 defer 会过早结束任务的上下文。

把阻塞点与退出确认接起来

最常见的缺口是：协程在等待任务通道，外层虽然检查过取消，真正的接收却没有退出分支。取消一旦发生，它仍可能停在接收处。需要在这一个等待点同时接收任务和取消信号，而不是只在循环顶部读取 Cause。

// 任务等待点同时关注取消；处理函数仍须自行支持中断
select {
case 

发送结果的地方同样可能阻塞。消费者已经离开时，无退出条件的发送会让发送者一直保留自己的局部对象。需要明确结果通道由谁接收、谁关闭，或者为发送增加取消分支。不要为了“释放通道”由任意接收方直接 close，关闭仍可能被发送的通道会产生另一类错误。

还要注意 select 不是强制中断机制：如果任务和取消都已就绪，并不保证总是先选取消。若业务要求取消后不得提交结果，应在提交层增加状态检查或事务规则，而不是依赖分支排列顺序。

按资源类型选择清理变体

文件：成功打开后立即在拥有者作用域登记关闭，并处理关闭错误。上下文取消不会替普通文件操作提供通用中断能力。若文件写入本身长时间阻塞，循环外层有取消分支也无法让那次调用立刻返回。

长时间 I/O：检查正在调用的具体 API 是否接收并遵循上下文。只把 ctx 传给上层函数不够；底层若不支持取消，需要依据该资源接口的文档选择截止时间或可行的关闭策略。共享连接不能因为一个子任务取消就被无条件关闭。

定时任务：创建派生上下文时保留相应取消函数；自己创建的计时器或周期器按其 API 管理。不要把上下文内部相关资源的清理与业务自行创建的对象混为一谈。

内存：业务已经结束但占用仍高，要检查任务队列、全局缓存、错误记录等是否仍引用大对象。一个可行的设计约束是让取消原因保持轻量，只保留错误类别和必要标识，避免把大批业务数据装入错误对象后再长期保存。进程内存没有立即下降也不等同于某个文件或协程泄漏。

处理取消原因与版本边界

Cause 与 WithCancelCause 从 Go 1.20 提供。取消前 Cause 返回 nil；通过 cancel(nil) 取消时，原因是 context.Canceled。已经确定的取消原因不会被后续一次取消调用改写，因此它不适合作为不断覆盖的“最后一次错误”存储。

父子上下文存在取消传播关系，排查时应记录到底读取了哪个上下文。不要看到某个原因就推断它一定来自当前函数：父级也可能先取消。若业务要保存多项错误，应使用独立的错误汇总机制，并定义它与取消原因的关系。

另一个容易混淆的变体是 WithTimeoutCause：它在超时发生时设置指定原因，返回的取消函数仍是无参数的 CancelFunc。不要把 WithCancelCause 的带参数调用形式直接套到它身上。提前主动取消和等到超时也不是同一种结果。

保存完整片段并回答常见疑问

下面是原创的函数级完整片段。任务函数同步持有文件；外部如将它放入协程，就必须等待它返回后再认定文件清理结束。示例使用独占创建，已有文件会返回错误，避免覆盖原文件。代码仅用于解释职责，没有在读者项目中执行。

package exportjob

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

// Export 接收数据块并写入新文件；调用方负责传入有效上下文
func Export(ctx context.Context, jobs 

StopExample 为了展示收尾关系，启动后立即发出停止请求；实际业务应把该请求放到真实的停止入口。这里等待 result 没有硬超时，若 Write 卡住，等待也可能持续。给等待加超时只能让等待者返回，不能证明写入者已经退出。生产中应根据底层资源能力设计可中断操作，不能用一段超时等待假装清理完成。取消后的部分文件在此示例中会保留，是否删除或改为临时文件提交，需要由导出业务另行定义。

Cause 非 nil 就代表协程退出了吗？不代表。需要业务函数返回、专用完成通道或其他明确的结束确认。

调用 cancel 后还需要 Close 吗？需要按资源接口和所有权处理。对这里由 Export 打开的文件，关闭由它自己的 defer 完成。

defer cancel(nil) 会冲掉原来的业务原因吗？已确定的原因不会被后续调用改写。正常返回时也应保留收尾取消，避免遗漏上下文相关清理。

排查记录应分别保留停止请求、任务返回和资源关闭错误。只有这几项各有明确的产生位置，才能区分“已经观察到取消”和“资源拥有者确实完成收尾”。官方实现参考：https://go.dev/src/context/context.go。