readtimeout 应设为 5s～15s，覆盖请求头与体到达最坏预期；writetimeout 设为 10s～30s，从响应头写入完成起计时；go 1.22+ 改用 readheadertimeout+idletimeout+context 控制。
ReadTimeout 设置太长会导致连接堆积
HTTP 请求卡在读取阶段（比如客户端发一半就断开、网络抖动、恶意慢速攻击），ReadTimeout 设得太长，net/http.Server 就会一直等，连接不释放，goroutine 堆积，最终耗尽内存或文件描述符。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
-
ReadTimeout应该覆盖「完整请求头 + 请求体到达」的最坏预期，一般设为5s～15s；上传大文件时可单独用http.MaxBytesReader控制请求体大小，而不是拉长 timeout - 不要设成
0（禁用）或30s+，除非你明确知道所有上游都是可控内网且无异常行为 - 如果用了反向代理（如 Nginx），注意它也有自己的 read timeout（如
proxy_read_timeout），要和 Go 的ReadTimeout对齐，否则可能被提前断连
WriteTimeout 不等于响应生成时间
WriteTimeout 从「响应头写入完成」开始计时，不是从 handler 返回开始。也就是说，handler 内部耗时再长，只要没调用 WriteHeader 或第一次 Write，就不触发 WriteTimeout；但一旦开始写响应，后续任何阻塞（如模板渲染慢、下游 RPC 卡住、日志同步刷盘）都会计入这个 timeout。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 典型值设为
10s～30s，比ReadTimeout略宽，因为响应阶段更难预测（比如 DB 查询、外部 API 调用） - 避免在 handler 中做同步 IO 或重计算；必须做的，用
context.WithTimeout单独控制，别依赖WriteTimeout当兜底 - 如果响应流式输出（如
io.Copy大文件、SSE），WriteTimeout会持续重置，实际生效的是「两次 write 之间的空闲时间」，这点容易误判
Go 1.22+ 的 ReadTimeout 和 WriteTimeout 已被弃用
从 Go 1.22 开始，ReadTimeout 和 WriteTimeout 字段标记为 deprecated，推荐改用 ReadHeaderTimeout、ReadTimeout（新语义）、WriteTimeout（新语义）组合，但注意：新 ReadTimeout 实际对应旧 ReadHeaderTimeout + Handler timeout，语义已变。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 升级到 Go 1.22+ 后，直接设
ReadHeaderTimeout（只管请求头，建议5s） +IdleTimeout（保活，建议60s） + 用context控制 handler 执行时间 - 旧代码里继续用
ReadTimeout/WriteTimeout不会报错，但 go vet 会警告，且未来版本可能移除 - 如果你用的是标准
http.Server，没有自定义 listener，IdleTimeout比KeepAliveTimeout更关键，它决定空闲连接何时关闭
超时设置无法覆盖 TLS 握手和 HTTP/2 帧解析
ReadTimeout 和 WriteTimeout 都不作用于 TLS 握手阶段；HTTP/2 下，单个连接复用多个 stream，这些 timeout 是 per-request 的，但底层连接的空闲、流控、帧解析失败不会触发它们。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- TLS 握手超时需靠
tls.Config.GetConfigForClient或外层net.Listener的 Accept 超时（如用net.Listen包一层带 timeout 的 listener） - HTTP/2 场景下，重点看
IdleTimeout和MaxConcurrentStreams，否则慢速 client 可能占满连接却不出错 - 线上务必开启
http.Server.ErrorLog并捕获http.ErrHandlerTimeout，这是唯一能确认是哪个 timeout 触发的信号
超时不是调越大越稳，而是要匹配你的协议栈层级、网络环境和业务 SLA。最容易被忽略的是：TLS 层、HTTP/2 流控、反向代理与 Go server 的 timeout 链路不一致，问题往往出在中间那一截没人盯的地方。
