应分情况处理：查文档确认隐藏支持、用 goroutine 包裹+协作退出、http 客户端须用 http.newrequestwithcontext、数据库操作须用 querycontext/execcontext、不可将 cancel 函数传给不可控第三方代码。
第三方库不支持 context 怎么办
Go 标准库（如 http.Client、database/sql）大多已适配 context.Context，但大量第三方库仍只接受超时参数或无取消机制。这时不能硬塞 ctx，而要分情况处理：
- 查文档确认是否隐藏支持：有些库虽未在函数签名暴露
ctx，但在内部调用标准库（如用http.DefaultClient），此时需手动替换为带 context 的实例 - 若库完全无取消能力（如纯计算型、阻塞式 Cgo 调用），只能靠外部信号+协作式退出：启动 goroutine 包裹该调用，并在外部用
ctx.Done()触发中断逻辑（例如关闭其依赖的 channel、设置标志位、调用其提供的 Stop() 方法） - 避免用
os.Interrupt或syscall.Kill强杀进程——这会跳过 cleanup，导致资源泄漏或状态不一致
HTTP 类第三方客户端必须用 http.NewRequestWithContext
很多封装了 http.Client 的 SDK（如 AWS SDK Go v2、Stripe Go、自研 REST 客户端）默认忽略传入的 context.Context，除非你显式构造带 context 的请求：
Go语言（Golang）1.26.0
下载
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
- 错误写法：
client.Get("https://api.example.com")—— 完全绕过 context 控制 - 正确写法：先用
http.NewRequestWithContext(ctx, "GET", url, nil)创建请求，再交由 client.Do(req) - 注意：即使 client 自带
Timeout字段，它只控制连接/读写阶段，和ctx的取消是两套机制；二者应配合而非替代 - 若 SDK 提供
WithContext(ctx)链式方法（如svc.ListObjectsV2Request(...).WithContext(ctx)），优先使用它，它通常已封装好底层 request 构造
数据库驱动类库要检查 QueryContext / ExecContext
像 pgx、sqlx、ent 这类 ORM 或驱动封装库，是否响应 context 取决于是否调用了上下文感知方法：
-
db.Query("SELECT ...")不受 context 影响；必须改用db.QueryContext(ctx, "SELECT ...") - 事务内操作同样需用
tx.QueryContext，否则ctx在事务开始后被 cancel，查询仍会继续执行 - 某些驱动（如旧版
lib/pq）对 context 支持不完整，超时后可能仍占用连接，建议升级到pgx/v5或确认驱动版本兼容性 - 连接池本身不响应 context，
ctx只影响单次查询生命周期，不是“断开整个连接池”
cancel 函数别传给不可控第三方代码
这是最容易被忽略的泄漏点：你把 cancel 函数作为参数传给某个第三方函数，但它没调用、忘了调用、或调用时机不对，就会导致子 context 永远不被释放。
- 永远不要把
cancel交给无法审查源码的闭源库或泛型回调接口 - 如果第三方库提供注册回调（如
OnFinish(func())），可包装一层：func() { select { case ，防止重复 cancel - 更安全的做法是：在调用第三方库前派生子 context，用
defer cancel()确保作用域结束即释放，而不是依赖它内部调用 - 特别警惕日志、监控、追踪类 SDK——它们常默默持有 context 并用于 span 生命周期，若传错会导致 trace 泄漏或 goroutine 堆积
ctx 超时后它可能还在做第 3 次重试的 DNS 查询——这时候 Done channel 关了，但 goroutine 还在跑。必须结合库的重试策略、底层 transport 行为、甚至 TCP 状态，才能让 cancel 信号真正落地。
