context cancel 后下游为什么仍然占用资源

context cancel 后下游仍占用资源，通常是因为取消只发出“这项工作不再需要”的信号：工作协程没有监听、阻塞调用没收到同一上下文，或者资源清理尚未完成。调用 cancel 不会强行终止 goroutine，也不会等待下游退出，更不等于远端任务已经停止。

把“已请求取消”“下游调用已返回”“资源已经关闭或归还”分别处理。取消链路要传到真正等待的操作，资源所有者要执行清理，需要确认退出时再等待独立的完成信号。

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

从资源占用现象区分取消、返回和释放

接口超时返回了，CPU 却继续增长；客户端取消了请求，数据库连接仍在使用；处理函数结束了，后台协程还卡在结果通道。这些现象看起来相似，实际涉及不同的生命周期。Context 提供取消协作机制，业务代码和依赖实现负责响应它。

ctx.Err() 说明上下文的取消状态，并不统计还剩多少工作。ctx.Done() 关闭也不是任务完成通知。即使下游调用已经返回，应用持有的响应体、结果集或本地缓冲对象仍可能需要清理；即使这些对象已释放，进程常驻内存也可能因运行时或池保留而没有立刻下降。

明确请求调用方与资源所有者的职责

先给每个资源确定所有者：创建派生上下文的一层负责调用取消函数；启动协程的一层负责组织退出等待；取得 HTTP 响应体或数据库结果集的一层负责关闭它。请求级取消不应直接关闭整个共享客户端或数据库连接池，否则会影响其他请求。

上下文关系也要连续。业务调用已经带着 ctx，下游却改成 context.Background()，等于建立了一棵独立的取消树。只有明确允许脱离请求的后台任务才应该这样设计，而且要有自己的期限、容量和结束管理。

让工作协程在阻塞点响应取消并报告退出

最小修复不是把计算套进另一个 goroutine，然后让外层在超时后直接返回。那只结束了等待者，底层计算可能继续运行。下面的完整示例同时处理任务接收和结果发送两个等待点，并通过独立的 done 通道通知退出。示例用于说明写法，没有附带实测结果。

package main

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

// forward 在取消时退出；done 只表示这个协程已经结束。
func forward(ctx context.Context, jobs 

如果只在接收任务时监听取消，处理完后直接 results ，消费者退出就可能让发送者永远等待。代码中的第二个 select 正是处理这个边界。输入关闭由生产者负责，不能为了取消而随意关闭仍有发送者使用的通道。

select 的多个分支同时就绪时没有“取消优先”的保证。示例中的单次计算很短，允许在竞争时多处理一个已就绪任务；昂贵 CPU 循环应拆成有界批次，在批次之间检查 ctx.Err()。已经进入的不支持取消的阻塞函数，不会因为外层存在 select 就自动中断。

把同一上下文传到 HTTP 与数据库调用

HTTP 应使用 http.NewRequestWithContext 把上下文绑定到请求。对于标准客户端请求，上下文覆盖获取连接、发送请求、读取响应头和响应体。下面是函数片段，所在文件需导入 context、net/http、io 和 fmt，并使用可复用的客户端。

// fetchSize 的 ctx 覆盖发请求和读响应体；调用方负责设置取消期限。
func fetchSize(ctx context.Context, client *http.Client, url string) (int64, error) {
    req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
    if err != nil {
        return 0, err
    }
    resp, err := client.Do(req)
    if err != nil {
        return 0, err
    }
    defer resp.Body.Close() // 读完、读失败、状态码异常都关闭响应体。
    if resp.StatusCode != http.StatusOK {
        return 0, fmt.Errorf("下游状态异常: %s", resp.Status)
    }
    // 限制读取量；超出上限直接报错，由 defer 关闭响应体。
    const maxBody = int64(2  maxBody {
        return n, fmt.Errorf("响应体超过读取上限")
    }
    return n, nil
}

不要在辅助函数里创建短期限上下文、defer cancel 后把尚未读取的响应体返回给外层；函数返回时取消会影响后续读取。可以像示例这样在同一作用域消费响应体，也可以把读取和清理的完整责任交给调用方。取消或提前结束读取可能影响连接复用，但这不是省略 Close 的理由。

数据库调用使用 QueryContext、ExecContext 等支持上下文的方法。获得 Rows 后安排 rows.Close()，遍历结束后处理 rows.Err()。具体数据库操作能否及时中断还取决于驱动和数据库能力，不能把方法名带 Context 理解为远端查询必定立即停止。

HTTP 官方文档：https://pkg.go.dev/net/http#NewRequestWithContext

数据库取消说明：https://go.dev/doc/database/cancel-operations

按依赖能力分阶段修复取消链路

调用链经过多层服务时，可以先处理本服务可控的协程和阻塞点，再补齐网络与数据库入口的上下文传递，最后明确远端任务的取消协议。调用方、服务开发者和依赖维护者分别负责不同部分，不能把所有资源继续占用都归结为 cancel 不生效。

对于不提供上下文、关闭或期限能力的旧库，外层超时只能限制调用方等待时间。要控制实际资源消耗，需要依赖自身的中断能力，或在设计中限制并发和积压；若工作运行在独立进程，还应由进程管理机制约束其生命周期。不要无限启动新协程来“隔离”同一个无法停止的调用。

取消也不是事务补偿协议。远端服务可能已提交写入，随后才感知连接断开；客户端得到取消错误时应按业务幂等键或任务状态处理结果不确定性，不能直接断言写入没发生。

用退出和资源归还指标判断是否完成

修复后的观察重点应放在“取消发生后，还有哪些工作未结束”。记录取消请求时刻与工作完成时刻的差值、仍存活任务数量、依赖调用返回耗时，以及数据库连接池的 InUse、WaitCount 等指标。指标用于定位残留位置，不能仅凭总 goroutine 数或 RSS 一次变化下结论。

如果应用完成信号迟迟不到，优先找协程仍停留的函数和等待点；如果调用已结束但结果集没有关闭，修复资源所有权；如果本地对象已释放而远端仍运行，处理远端能力与协议边界。判断标准是请求关联工作在约定期限内结束、资源得到归还，而不是要求所有共享空闲资源消失。

常见问题

defer cancel 就能防止协程泄漏吗？

不能。它释放派生上下文相关资源并发出取消，协程仍须在等待点或计算边界响应；调用方需要退出确认时还要组织等待。

cancel 可以调用多次吗？

可以，首次取消后的重复调用不会重新取消一遍工作；它也不会因此变成等待工作结束的操作。

context 已取消，数据库连接还在是否一定是泄漏？

不一定。要分清正在使用的连接与池内空闲连接，再结合驱动取消能力、调用是否返回、结果集是否关闭定位。

本地请求取消能保证远端业务撤销吗？

不能。请求生命周期管理与业务撤销是两种约定，远端已完成的副作用需要业务协议处理。