go重放http请求需重建body并修正header，避免closed body错误；handler中panic若无recover会静默失败；判断client/server故障需抓包分析tcp连接；幂等性须在业务层校验持久化key。
Go 命令模式怎么安全地重放 HTTP 请求
命令模式本身不处理网络，但用它封装请求时，容易在重放时触发副作用（比如重复扣款）。关键不是“能不能重放”，而是“重放前是否清除了不可复用状态”。
常见错误现象：http.Request 的 Body 是 io.ReadCloser，一旦读取就关闭；重放时直接复用原请求会报 http: read on closed body。
- 必须用
httputil.DumpRequestOut+http.ReadRequest重建请求，或提前用io.ReadAll缓存Body并用bytes.NewReader重新注入 - 注意
Header中的Content-Length和Transfer-Encoding，手动重建时需同步修正，否则服务端可能拒绝 - 如果用了
context.WithTimeout，重放时得新建 context，旧的 context 可能已取消
bodyBytes, _ := io.ReadAll(req.Body) req.Body = io.NopCloser(bytes.NewReader(bodyBytes)) // 可重放一次 // 若需多次，每次都要 new 一个 bytes.NewReader
Go Web 服务中哪些 panic 会导致请求被静默吞掉
HTTP handler 里 panic 不会直接崩进程，但默认 recovery 行为是写日志 + 返回 500，而很多中间件（比如 gorilla/mux、chi）没开 recover，结果就是连接断开、客户端收不到响应、日志也空——你以为请求“消失了”。
使用场景：线上突然出现大量超时或空响应，net/http 默认日志里却看不到对应条目。
立即学习“go语言免费学习笔记（深入）”；
-
panic发生在http.ServeHTTP调用链之外（比如 goroutine 异步执行中），完全不会被捕获 - 即使开了 recover，如果 panic 在
defer里又引发新 panic，原始错误会被覆盖 -
log.Fatal或os.Exit不是 panic，但效果更糟：整个 server 进程退出，且无堆栈提示
如何判断 Go HTTP 服务的故障是出在 client 还是 server 端
别急着改代码，先看连接生命周期。Go 的 http.Transport 默认复用连接，但某些错误（如 read: connection reset by peer）看起来像服务端问题，其实是 client 主动关了连接。
性能 / 兼容性影响：gRPC-Web、反向代理（Nginx）、TLS 握手失败都会伪造类似错误，不能单凭错误字符串下结论。
- 抓包看 TCP 层：如果 client 发了
FIN后 server 才回RST，问题在 client（比如超时后主动断连） - 检查
http.Client.Timeout和http.Server.ReadTimeout是否冲突，前者默认 0（无限），后者若设太小，server 会先关连接 - 用
curl -v对比：如果 curl 正常但 Go client 报错，大概率是Transport配置或 TLS 设置差异
Go 中重放请求时怎么避免重放幂等性漏洞
重放本身不等于幂等。你加了 X-Request-ID，但没在业务层校验，照样会重复写 DB。命令模式只是帮你把“重放动作”封装起来，不解决语义问题。
容易踩的坑：以为加了 If-None-Match 或 ETag 就安全，其实这些只对 GET 有效，POST/PUT 重放照样执行。
- 必须在 handler 入口做幂等 key 校验，key 应包含业务唯一标识（如订单号）+ 操作类型，不能只依赖请求头
- 幂等 key 生效时间要覆盖重放窗口，Redis 过期时间建议 ≥ 最大重试间隔 × 2
- 如果用
sync.Map做内存级幂等，重启即失效，只适合开发调试
复杂点在于：幂等校验和业务逻辑的事务边界必须一致。校验通过后进 DB 写入失败，下次重放仍应拒绝——这意味着校验动作本身也要持久化，不能只靠内存或临时缓存。
