gin设请求超时必须用context.withtimeout+中间件+业务层监听三者缺一不可，因readtimeout/writetimeout是全局连接级配置，无法按路由动态控制、不透传至handler、触发后直接断连且无法自定义响应。
Gin 里设请求超时，不能只靠 http.Client.Timeout 或裸写 time.After，必须用 context.WithTimeout + 中间件 + 业务层显式监听，三者缺一不可。
为什么 Gin 自带的 engine.ReadTimeout / WriteTimeout 不够用
这两个字段是 HTTP server 层级的全局设置，作用于整个连接生命周期（包括 TLS 握手、header 解析、body 读取），无法区分路由、无法动态调整、也不透传到 handler 内部。一旦触发，直接关闭连接，连 408 Request Timeout 都没法自定义返回体。
- 它们对长轮询、文件上传、流式响应等场景完全不友好
- 无法和 traceID、用户权限等上下文信息绑定
- 超时后 gin 不会自动调用
c.Abort()，后续中间件仍可能执行
用 context.WithTimeout 写中间件的正确姿势
核心是：创建 ctx → 替换 c.Request → 调 c.Next() → 检查 ctx.Err() → 立即 c.Abort()。
-
c.Abort()必须加，否则超时后dataHandler还会继续跑 - 中间件只负责兜底响应，业务 handler 内部仍要检查
c.Request.Context().Err() == context.DeadlineExceeded - 如果 handler 启了子 goroutine（比如异步发消息），必须把
c.Request.Context()显式传进去，并在循环中 select 监听ctx.Done() - 别忘了
defer cancel()，否则高频请求下 timer 和 channel 会缓慢泄漏内存
HTTP Client 发起下游调用时的超时陷阱
你在 Gin handler 里用 http.Client 调第三方 API？光设 client.Timeout 是无效的，因为：
-
client.Timeout只在Do()开始时生效，若你先调req.WithContext(ctx)，则ctx超时优先级更高 - 必须确保
req = req.WithContext(c.Request.Context())，而不是context.Background() - 如果用了自定义
http.Transport，DialContext、TLSHandshakeTimeout等也得配合 ctx，否则连接卡住时 context 信号传不下去 - 常见错误：写了
select { case 却没监听 <code>ctx.Done()，结果超时根本不停
容易被忽略的底层细节
超时不是“时间到了就停”，而是信号传播 + 底层协同。比如：
- TCP
Read()前必须调conn.SetReadDeadline()，且每次读前都要重设——deadline 是绝对时间点，只对下一次生效 - 数据库查询要用
db.QueryContext()、tx.ExecContext()，不能用老接口Query() - 日志、metrics 上报等“收尾操作”如果也耗时，得包在
select里监听ctx.Done()，否则超时响应发出去了，后台还在打日志
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
