gorm操作必须接收ctx参数，因依赖数据库i/o；纯内存函数无需ctx。推荐操作级超时：db.withcontext(ctx).find()，全局设defaultcontexttimeout和defaulttransactiontimeout，并注意defer cancel()防泄露。
哪些函数必须接收 ctx context.Context 参数
只有可能阻塞、发起 I/O 或启动需响应取消的 goroutine 的函数才需要显式接收 ctx。比如：http.Client.Do、sql.DB.QueryContext、grpc.ClientConn.Invoke、gorm.DB.Find 这类底层依赖网络或数据库的操作。
纯内存计算函数（如 calculateHash、json.Unmarshal）传 ctx 是冗余的，既无实际作用，又破坏函数职责边界和单元测试可隔离性。
- HTTP handler 中必须用
r.Context()，绝不能新建context.Background() - 封装了 I/O 的业务函数（如
fetchOrder(ctx, id)）要透传ctx，而不是在内部硬编码 - 多个 I/O 步骤串联时，同一个
ctx应贯穿全程，避免中途丢失取消信号
context.WithTimeout 和 context.WithDeadline 怎么选
选哪个取决于你控制的是“持续时间”还是“绝对时间点”：
- 用
context.WithTimeout：适合“最多等 5 秒”，比如下游 HTTP 调用、缓存查询、单次 DB 查询 - 用
context.WithDeadline：适合“必须在 2026-06-13T08:30:00Z 前完成”，比如分布式锁续期、定时任务保活、跨服务协调截止时间
关键细节：
- 两者都会自动关闭
Done()，但cancel()必须显式调用，否则 timer 不释放、goroutine 泄露 ——defer cancel()是高频遗漏点 -
WithDeadline若传入已过期时间，ctx.Err()立即返回context.DeadlineExceeded - 不要对同一
ctx多次套用WithTimeout，子上下文 deadline 是叠加的，容易误判超时逻辑
GORM 操作中如何正确设置超时
GORM 提供两层超时控制：全局默认值 + 操作级覆盖。优先用操作级，避免一刀切影响所有查询。
- 初始化时设全局超时：
DefaultContextTimeout: 30 * time.Second（普通查询）、DefaultTransactionTimeout: 60 * time.Second（事务） - 关键路径单独控制：
ctx, cancel := context.WithTimeout(parentCtx, 10*time.Second)，再db.WithContext(ctx).Find(&users) - 事务内每个操作都继承事务上下文，所以事务级超时应比单次查询更宽松，否则可能提前中断整个事务
- 注意 GORM 的
WithContext是链式方法，不修改原db实例，别漏掉调用
最容易被忽略的三个坑
不是加了 ctx 就算安全了，真正出问题的地方往往藏在细节里：
-
defer cancel()写在错误分支之后？—— 如果err != nil就 return，cancel()永远不会执行，timer 泄露 - 把
ctx.Value当成通用状态容器乱塞数据？—— 键类型没用自定义 struct，不同包用相同字符串键互相覆盖 - HTTP handler 里用
context.WithTimeout(r.Context(), ...)，但没检查r.Context().Err()是否已取消？—— 可能刚进 handler 就该退出，却还继续构造参数、查 DB
复杂点在于：超时不是孤立配置，它必须和调用链路、服务依赖、重试策略联动。一个接口超时设短了，下游还没来得及重试就断了；设长了，又拖垮上游整体 P99。真正难的是平衡。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
