Go HTTP 服务超时参数别乱配：从 ReadTimeout 到 Context 的边界

Go 做 HTTP 服务很方便，但也正因为起步简单，很多项目上线很久之后才发现超时控制其实没配完整。请求偶尔卡住、连接拖很久、下游调用不返回、goroutine 越积越多，这些问题很多都和超时边界没设好有关。

HTTP 服务稳定性最容易被误解的一点是：并不是配了一个 timeout 就算做完了。连接读写、请求处理、下游调用和业务生命周期，其实是几层不同的边界。

先分清楚：连接超时和业务超时不是一回事

很多人会把所有超时都理解成“请求多久不返回就算超时”。但在 Go HTTP 服务里，更应该拆开看：

1. 连接读超时
2. 连接写超时
3. handler 处理超时
4. 下游调用超时

如果这几层混在一起，后面排查时你很难知道到底卡在哪。

`ReadTimeout` 保护的是“读请求边界”

ReadTimeout 更多是在保护服务端别被慢速请求一直拖着。它解决的是：

1. 客户端迟迟不把请求头或请求体发完
2. 恶意或异常连接长时间占住服务端资源

如果没有这一层，连接层就可能先被拖垮。

`WriteTimeout` 保护的是“响应输出边界”

不少人配了读超时，却忘了写超时。结果服务端业务明明已经处理完了，但客户端接收很慢，响应写出阶段依然可能卡住。

所以只守“能不能读进来”还不够，还要守“能不能及时写出去”。

`IdleTimeout` 很适合放在长连接场景里看

如果你用了 keep-alive，连接不可能每次请求后都立刻断开。这时候空闲连接能挂多久，就会直接影响资源占用。

IdleTimeout 的价值就在这里：它控制的是空闲连接不要无限挂着。

对有一定并发的服务来说，这一步很值得补，不然连接池和文件描述符都可能被慢慢吃掉。

只有 server 超时还不够，下游调用也得有边界

很多线上卡死问题，不是 handler 自己逻辑复杂，而是 handler 里去调了：

1. HTTP 下游
2. Redis
3. MySQL
4. RPC 服务

如果这些调用没有明确超时，哪怕你的 HTTP server 自己参数配得不错，请求仍然可能卡在业务链路中间。

所以更稳的做法通常是：

1. server 层有连接超时
2. handler 层有 context 边界
3. 下游客户端也各自带 timeout

三层都做，系统才更稳。

`context.Context` 更适合承接业务取消

很多项目会在某个局部自己开 timer 或 sleep 去“模拟超时”，这往往不够统一。更适合 Go 服务的方式通常还是基于 context.Context 传递取消信号。

这样好处很直接：

1. handler 超时可以传递给下游
2. 客户端断开时，业务有机会感知
3. 异步任务也能根据上下文及时退出

如果没有这一层，很多请求虽然对用户已经结束了，但后台逻辑还在继续跑。

超时太短和太长都不稳

超时参数不是越短越高级。太短了会让正常请求也频繁失败；太长了又失去保护意义。

更合适的做法通常是根据接口类型分层：

1. 轻量查询接口超时更短
2. 文件上传下载接口更宽松
3. 高成本聚合接口要有明确上限
4. 后台任务型请求尽量异步化

也就是说，超时不是一刀切，而是跟业务成本绑定。

排查卡顿时最好沿这条线去看

如果你发现 Go HTTP 服务有偶发卡顿，我更建议按下面的顺序查：

1. 先看连接数和 goroutine 数
2. 再看 server 层 timeout 是否完整
3. 再看 handler 有没有 context 边界
4. 最后看下游依赖是否设置了独立 timeout

这样比一上来就怀疑框架或系统抖动更有效。

一个更适合中小 Go 服务的默认思路

如果你现在的服务还不大，我更建议先做到：

1. `ReadTimeout`
2. `WriteTimeout`
3. `IdleTimeout`
4. handler 统一 context 超时
5. 所有下游客户端带 timeout

这几步不复杂，但已经能挡掉很多常见的卡死和资源泄漏问题。

结语

Go HTTP 服务的超时控制真正重要的，不是记住几个参数名，而是知道每一层在保护什么。只要把连接层、处理层和下游层的边界都补齐，服务稳定性通常会明显好很多。

对中小型服务来说，这种“边界清楚的超时体系”比单纯把某个值调大或调小更有意义。