不能复用同一context.context给所有批次，因子context超时或取消后永久失效，会导致后续批次立即失败；应每批用context.withtimeout(parentctx, batchtimeout)新建独立context，确保各批次生命周期隔离。
为什么不能直接把同一个 context.Context 传给所有批次？
因为 context.WithTimeout 或 context.WithCancel 创建的子 context 是“一次性”的：一旦超时或被取消，它和它的所有子 context 都永久失效。如果你用一个父 context 启动 10 批插入，第 3 批中途超时，后续批次调用 db.ExecContext 会立即返回 context.DeadlineExceeded 或 context.Canceled，哪怕它们根本还没开始执行。
真正需要的是每批拥有独立生命周期的 context —— 要么各自带独立超时，要么能单独取消某一批而不影响其他批。
怎么为每批插入创建独立的 context.Context？
最稳妥的做法是：在循环内为每一批次显式派生新 context。不要复用外层传入的 context，也不要提前派生好再切片传递。
- 用
context.WithTimeout(parentCtx, batchTimeout)每次都新建，batchTimeout建议设为单批预期耗时的 2–3 倍（比如 5s），避免因网络抖动误杀 - 如果想支持整体取消（如用户主动中止整个导入任务），可先用
context.WithCancel得到一个可取消的父 context，再用它作为WithTimeout的 parent - 别用
context.Background()或context.TODO()替代——它们无法响应取消信号，违背批量控制初衷
示例关键片段：
parentCtx, cancel := context.WithTimeout(ctx, totalTimeout) defer cancel() for i := 0; i <h3>循环里用 <code>defer batchCancel()</code> 会出什么问题？</h3> <p>Go 中 <code>defer</code> 语句注册在函数退出时执行，不是在当前作用域结束时。放在 for 循环里会导致所有 <code>batchCancel()</code> 堆积到外层函数 return 时才集中调用 —— 最后一批的 cancel 可能延迟数秒甚至更久，泄漏资源、阻塞连接池回收。</p><div class="aritcle_card flexRow artxards"> <div class="artcardd flexRow"> <a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill6668" title="DrugBank 数据库"><img src="https://img.php.cn/upload/skill/000/000/081/179108121375956.jpg" alt="DrugBank 数据库" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a> <div class="aritcle_card_info flexColumn"> <a rel="nofollow" href="/xiazai/skill6668" title="DrugBank 数据库" class="overflowclass">DrugBank 数据库</a> <p class="overflowclass">访问并分析来自 DrugBank 数据库的全面药物信息，包括药物属性、相互作用、靶点、通路、化学结构和药理学数据。用于药物数据、药物发现研究、药理学研究、药物-</p> </div> <a rel="nofollow" href="/xiazai/skill6668" title="DrugBank 数据库" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span> </a> </div> </div>
- 正确做法：不用
defer，显式调用batchCancel()，且必须在该批次操作完成后立刻执行（无论成功失败） - 更安全的写法是用
func() { ... }()匿名函数包裹，确保 cancel 在当次迭代末尾触发 - 如果用了
sql.Tx，还要注意：tx.Commit()或tx.Rollback()后再 cancel 才合理，否则可能中断事务内部清理
要不要在每批里检查 ctx.Err() == context.Canceled？
通常不需要手动检查。只要把正确的 batchCtx 传给 db.ExecContext 或 tx.StmtContext，底层驱动（如 lib/pq 或 mysql）会在 SQL 执行前/中自动检测 context 状态并提前返回错误。你只需处理 err != nil 即可。
但有两个例外场景值得加检查：
- 批次数据预处理很重（如 JSON 解析、加密计算），且可能耗时超过 timeout —— 这时应在计算前插一句
if err := batchCtx.Err(); err != nil { return err } - 使用了自定义重试逻辑，在重试前需确认 context 是否还有效，否则可能无限重试已取消的任务
记住：context 的核心价值是“及时中断”，不是“轮询状态”。依赖驱动原生支持比自己满处检查更可靠。
分批 context 的关键不在“怎么传”，而在“谁负责取消”和“何时取消”。漏掉一次 cancel()，就可能让 goroutine 和数据库连接卡住几秒甚至几分钟 —— 这类问题在线上往往表现为连接池耗尽，而不是明显的 panic 或 error 日志。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
