Go HTTP 服务 Timeout 为 0 会有什么风险

先说结论：Go 的 http.Server 中，ReadTimeout、WriteTimeout 为 0 或负数时表示对应方向不设超时；IdleTimeout 为 0 时会使用 ReadTimeout 的值，如果两者都为 0（或负数），keep-alive 连接等待下一个请求也没有超时。这样写能让最简单的服务运行起来，但在公网服务中可能让慢请求、慢响应或长期空闲连接一直占用资源。

官方文档：https://pkg.go.dev/net/http#Server

更稳妥的做法不是把三个字段机械地改成同一个数字，而是先按调用方体验划分边界：请求读取有自己的预算，响应写出有自己的预算，连接复用也有自己的空闲预算。

三个字段分别管什么

http.Server 的零值本身是可用的，这也是很多示例直接调用 ListenAndServe 的原因。但“可用”不等于“已经配置了生产级截止时间”。三个字段作用在不同位置，混在一起看就容易误判。

这里的“超时”是 Server 侧的连接读写截止时间，不是 Handler 自己的业务超时，也不是客户端 http.Client.Timeout。客户端提前断开、Handler 返回业务错误和网络读写到达截止时间，处理路径并不相同。

ReadTimeout 为 0，慢请求可以拖多久

ReadTimeout 覆盖读取整个请求，包括 body。它为 0 时，Server 不会因为读取时间本身结束连接。典型风险是客户端发送请求头或请求体很慢，连接和处理 goroutine 长时间处于等待状态；当并发连接增多时，资源压力会比本地快速请求更明显。

如果接口允许大文件上传，不能简单地把 ReadTimeout 调得极短，因为慢速但合法的上传也会被截断。更常见的取舍是把请求读取预算设为一个明确上限，并在 Handler 内根据业务限制请求体大小；不要把“允许大 body”误解成“允许无限慢”。

package main

import (
    "log"
    "net/http"
    "time"
)

func main() {
    server := &http.Server{
        Addr: ":8080",
        // 给读取请求设上限，避免慢客户端无限期占住连接。
        ReadTimeout: 30 * time.Second,
        Handler: http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
            // 业务层仍应按接口需要限制 body 大小，而不是只依赖时间。
            http.MaxBytesReader(w, r.Body, 2

示例中的 30 秒只是配置示例，不是通用答案。上传接口应结合文件大小、网络环境和反向代理的限制一起确定预算。

WriteTimeout 为 0，慢响应会留下什么问题

WriteTimeout 控制响应写出前允许等待的时间，并在读取新请求头时重置。它为 0 时，Server 不会在这一层替你结束慢写出。一个 Handler 如果持续生成内容，或者对端读取响应非常慢，连接就可能长期保持。

这里要注意错误归属：WriteTimeout 不是业务超时。Handler 内部访问数据库、调用下游或执行计算的时间，仍然应该由请求上下文、下游客户端和业务逻辑管理；Server 的写超时只是最后一层网络边界。

func newServer(handler http.Handler) *http.Server {
    return &http.Server{
        Handler: handler,
        // 给响应写出设边界，避免异常慢的对端无限拖住连接。
        WriteTimeout: 30 * time.Second,
        // 空闲连接采用独立预算，不把响应写出时间混进来。
        IdleTimeout: 60 * time.Second,
    }
}

如果接口确实需要长时间流式输出，不能只把 WriteTimeout 设成很小的固定值。应该先明确流式接口的生命周期，再选择更合适的连接策略和上游取消方式，否则正常响应也会被误杀。

IdleTimeout 为 0，不等于总是使用默认 60 秒

这是最容易被忽略的边界：IdleTimeout 为 0 时，Server 会回退到 ReadTimeout；如果 ReadTimeout 也为 0 或负数，就没有 keep-alive 空闲超时。也就是说，下面这段配置虽然显式写了 IdleTimeout: 0，实际效果仍取决于 ReadTimeout。

server := &http.Server{
    // ReadTimeout 为 0 表示读取方向不设超时。
    ReadTimeout: 0,
    // IdleTimeout 为 0 会回退到 ReadTimeout，因此这里仍没有空闲超时。
    IdleTimeout: 0,
}

长时间保留空闲连接并不一定立刻报错，但会增加文件描述符、连接跟踪和内存占用的持续时间。对需要连接复用的服务，通常应显式设置一个与客户端重用策略相容的 IdleTimeout，让“多久没有下一个请求”成为可读的接口约束。

超时后的错误应该由哪一层处理

把超时字段配上，并不意味着所有异常都能统一返回一个 JSON 错误。读取阶段可能还没有完整请求，Server 没有稳定的业务响应机会；写出阶段则可能已经写出部分内容，调用方也未必能收到完整错误体。

日志里应记录请求方法、路径、耗时和连接关闭原因，但不要把“写超时”直接等同于业务失败。对于幂等请求可以由调用方重试；对于已经产生副作用的请求，重试策略必须由业务定义。

一组更容易维护的基础配置

如果没有特殊的长连接或大文件需求，可以把三个预算集中写在 Server 初始化处，并用注释说明它们解决的风险。这样后续复制服务模板时，不容易悄悄恢复成全部零值。

func buildServer(handler http.Handler) *http.Server {
    return &http.Server{
        Addr: ":8080",
        Handler: handler,
        // 控制请求读取总时长，慢客户端不能无限等待。
        ReadTimeout: 30 * time.Second,
        // 控制响应写出时长；长流式接口需要单独评估。
        WriteTimeout: 30 * time.Second,
        // 控制 keep-alive 空闲等待，避免依赖 ReadTimeout 的隐式回退。
        IdleTimeout: 60 * time.Second,
    }
}

落地时可以按下面的顺序检查：

1. 确认三个字段的单位都是 time.Duration，不要把整数当成秒直接填写。
2. 确认没有用 IdleTimeout: 0 误表达“使用某个安全默认值”。
3. 确认上传和流式接口是否需要不同的时间预算或专门的处理路径。
4. 确认代理、客户端和 Server 的边界不会互相等待到更长的一侧。

常见问题

Server 的零值能不能直接用于生产？能启动，但它没有替你建立读取、写出和空闲连接的时间边界。是否适合生产取决于部署环境，公网服务通常不应把零值当成完整配置。

只设置 ReadTimeout，IdleTimeout 会怎样？IdleTimeout 为 0 时回退到 ReadTimeout，因此两者会共享这个值；如果想让 keep-alive 空闲时间独立，应显式设置 IdleTimeout。

WriteTimeout 会限制 Handler 的执行时间吗？它描述响应写出的时间边界，不是通用业务执行预算。数据库、下游 HTTP 调用和计算任务仍应使用各自的上下文或客户端超时。

把所有 Timeout 都设成 10 秒是否最好？不一定。上传、普通 JSON 接口和流式输出的正常时长不同，应按调用方需求分配预算，并为长连接场景单独说明例外。

总结：Timeout 为 0 的主要风险不是程序立刻启动失败，而是 Server 缺少明确的资源释放边界。先分清读取、写出、keep-alive 三个责任面，再决定哪些字段需要独立配置，通常比给所有字段填同一个数字更可靠。