Go HTTP/2客户端收到 GOAWAY 后重试策略怎么处理

Go HTTP/2 客户端收到 GOAWAY 后，不能把所有失败请求都重发一遍。正确的判断顺序是：先看 GOAWAY 的 last-stream-id 能否说明请求可能没有被服务端处理，再看请求方法是否允许重复执行，最后确认请求体能否重新读取。对于普通 net/http.Client，GOAWAY 的底层细节通常被 Transport 封装，业务代码更应该围绕“可重放”和“副作用”设计策略。

最稳妥的做法是：幂等且可重放的请求允许在新连接上有限重试；可能已经产生副作用的 POST 不要仅凭连接错误重试，除非服务端提供幂等键或明确的去重语义。重试要有次数、退避和上下文上限。

官方资料：https://pkg.go.dev/net/http

• GOAWAY 的含义：连接停止接受新的流，但已经建立的流仍可能继续完成。
• 判断依据：服务端发送的 last-stream-id 只说明哪些流可能被处理，不能直接当成业务成功或失败。
• Go 的边界：net/http 内部会处理一部分连接重试，应用层不要依赖未导出的 HTTP/2 错误类型。
• 重试条件：方法语义、请求体是否可重放、是否已写入服务端以及服务端是否支持幂等键，缺一不可。

先把 GOAWAY 和业务失败分开

一次常见的故障现场是：客户端复用一条 HTTP/2 连接发送多个请求，服务端准备维护或关闭连接，于是发送 GOAWAY。假设帧里的 last-stream-id 是 13，而客户端刚创建的请求流编号是 15，那么 15 号流可能根本没有被服务端处理，可以在新连接上重新发起。反过来，编号不大于 13 的流可能已经被上层业务读取，客户端只看到连接被关闭时，不能据此断言服务端没有执行。

RFC 9113 还允许服务端连续发送多次 GOAWAY，后一个帧可以把最后流编号收窄。因此“收到一次 GOAWAY 就马上把所有 in-flight 请求重试”并不安全。对 GET、HEAD 这类天然幂等操作，重试通常是合理的；对 PUT、DELETE 也要结合接口的实际语义；对 POST、支付、扣库存或创建任务等操作，必须先解决重复副作用问题。

Go net/http 为什么不能直接给你一个 GOAWAY 开关

Go 的标准客户端默认支持 HTTP/2，但协议实现细节位于 Transport 内部。应用层通过 Client.Do 或 Transport.RoundTrip 看到的是响应或错误，不应把某个错误字符串当成稳定的 GOAWAY API。当前 Transport 的内部重试判断会关注连接是否复用、请求是否可重放，以及请求体能否通过 GetBody 重新建立。

这也是很多“偶发重试失败”的真正原因：GET 没有请求体，Transport 可以在特定连接错误下换一条连接；而带流式 Body 的 POST 如果没有 GetBody，第一次发送后就无法安全地复制内容。下面的检查函数不读取未导出的 HTTP/2 状态，只把业务决策需要的三个条件显式化。

package retry

import "net/http"

// replayable reports whether the request body can be recreated for another attempt.
// 无请求体通常可以重放；有请求体时必须由 GetBody 提供新的读取器。
func replayable(req *http.Request) bool {
	return req.Body == nil || req.Body == http.NoBody || req.GetBody != nil
}

// idempotentMethod keeps the automatic policy conservative.
// POST 不因为“看起来像临时网络错误”就默认重试，以免重复创建业务对象。
func idempotentMethod(method string) bool {
	switch method {
	case http.MethodGet, http.MethodHead, http.MethodPut, http.MethodDelete, http.MethodOptions:
		return true
	default:
		return false
	}
}

// canRetry separates transport policy from HTTP/2 frame parsing.
// 应用层不依赖未导出的 GOAWAY 类型，而是把幂等性和可重放性作为硬条件。
func canRetry(req *http.Request) bool {
	return idempotentMethod(req.Method) && replayable(req)
}

如果业务确实需要重试 POST，应把请求级幂等键传给服务端，并让服务端按键保存第一次结果。这样即使客户端不知道请求是否已经被 GOAWAY 前的流处理，也能把第二次请求变成“查询并复用同一业务结果”，而不是无条件再执行一次。

在新连接上做有限重试，而不是无限循环

应用层通常不需要手动创建 HTTP/2 连接。让共享的 http.Client 继续使用 Transport，重试时重新构造一个 Request 即可；Transport 会为下一次请求选择可用连接。示例把 Body 放在内存字节中，因此每次循环都能重新创建请求，适合展示策略，不适合直接套到超大上传。

package retry

import (
	"bytes"
	"context"
	"errors"
	"io"
	"net"
	"net/http"
	"time"
)

// DoIdempotent sends a replayable idempotent request at most three times.
// 只把连接级暂时错误纳入重试，业务响应和上下文取消都交给调用方处理。
func DoIdempotent(ctx context.Context, client *http.Client, method, url string, body []byte) (*http.Response, error) {
	if !idempotentMethod(method) {
		return nil, errors.New("request method is not covered by the idempotent policy")
	}

	const maxAttempts = 3
	for attempt := 1; attempt 

把故障证据记录到能做决定的字段

不要只记录“HTTP/2 重试了一次”。至少保存请求方法、是否有 Body、是否存在 GetBody、请求是否来自复用连接、错误类别、尝试次数和最终结果。若能从客户端或代理日志拿到 GOAWAY 的 last-stream-id、错误码和调试数据，也可以把它们作为诊断字段，但不要把调试数据当成可依赖的业务语义。

复查时可以按下面的顺序定位：

1. 先确认是不是连接级错误，而不是服务端已经返回的 4xx 或业务失败。
2. 再确认请求是否幂等；不幂等请求优先走幂等键、状态查询或人工补偿。
3. 确认 Body 是否可重新创建，避免第二次请求发送空内容或半截内容。
4. 限制最大次数和退避时间，观察重试后的成功率、重复业务数和连接新建数量。

常见问题

收到 GOAWAY 就一定要重试吗？

不一定。GOAWAY 只说明连接不再接受新的流，并通过最后流编号描述可能已处理的范围。已经拿到响应的请求不需要重试；可能产生副作用的请求也不能仅凭连接关闭就重试。

能不能在 Go 里直接判断 GOAWAY 的 last-stream-id？

使用普通 net/http.Client 时，HTTP/2 帧状态不是稳定的业务 API。若确实需要协议级观测，应在受控的 HTTP/2 组件或代理层记录帧信息，同时仍以请求幂等性决定是否重放。

POST 没有 GetBody 时，为什么不能自动重试？

请求体通常已经被读取，客户端无法确认第二次发送的是完整原文。更重要的是，第一次请求可能已经在服务端产生副作用。没有可重放 Body 和服务端幂等键时，宁可返回错误并进入补偿流程。

如何避免 GOAWAY 导致重试风暴？

限制每次请求的尝试数，使用带上下文取消的退避，给共享客户端设置合理的连接和超时配置，并把重试原因与最终结果分开计数。不要在每个调用点无限递归调用 Client.Do。

总结起来，GOAWAY 的处理重点不是“找到一个神奇的重试错误码”，而是把协议边界翻译成业务安全策略：能确认未处理且可重放的请求才重试；无法确认副作用的写请求使用幂等键或补偿；所有重试都必须有上限、退避和可观测证据。