Go服务需彻底无状态：状态外移至Redis/etcd，禁用sync.Map和包级变量；HPA应基于QPS或p95延迟等自定义指标，避免CPU毛刺误触发；ReadTimeout慎用，优先ReadHeaderTimeout+MaxBytesReader；Service Mesh下Client超时需覆盖sidecar延迟，健康检查需独立server与短超时。
Go 服务如何设计成真正无状态
无状态不是删掉全局变量就完事，而是所有请求的处理结果不能依赖本地内存、文件或未持久化的缓存。Go 里最容易踩坑的是 sync.Map 或包级变量偷偷存了用户会话、计数器、连接池元数据——这些在多实例下立刻不一致。
- 把会话、临时状态全部外移到
Redis或etcd，连 token 解析后的userClaims都别缓存在进程内 - HTTP handler 中避免闭包捕获外部变量（比如用
func() http.HandlerFunc工厂函数时传参不干净） - 数据库连接池用
sql.DB自带的连接复用机制，别自己 newsql.Conn并长期持有 - 日志打点用结构化字段（
log.With().Str("req_id", id)），别靠 goroutine ID 或本地 map 做上下文追踪
Horizontal Pod Autoscaler 怎么配才不翻车
K8s 的 HPA 默认看 CPU，但 Go 服务常因 GC 峰值或阻塞型 I/O 导致 CPU 毛刺，误触发扩缩容。更稳的方式是基于自定义指标，比如每秒请求数（QPS）或 p95 延迟。
- 用
prometheus.ClientGolang暴露http_requests_total和http_request_duration_seconds，再通过prometheus-adapter注册为 HPA 可读指标 - HPA 的
targetAverageValue别设太低（如 QPS=5），否则单个 Pod 突发慢请求就会拉高平均值，引发震荡 - 设置
minReplicas: 2，避免缩容到 1 后某节点故障直接雪崩 - Go runtime 指标如
go_goroutines可辅助诊断，但它不是扩缩容依据——goroutine 多只说明有积压，未必是负载高
为什么 net/http.Server 的 ReadTimeout 要慎用
Go 1.8+ 默认禁用了 ReadTimeout，因为它是从 accept 连接开始计时，包含 TLS 握手、HTTP 头解析、甚至 body 读取前的等待——对长轮询或上传大文件的服务，它会误杀合法连接。
- 改用
ReadHeaderTimeout控制 header 解析耗时（推荐 5–10s） - body 读取超时用
http.MaxBytesReader包一层，比如http.MaxBytesReader(w, r, 10*1024*1024) - 如果真要用
ReadTimeout，必须配合WriteTimeout且两者相等，否则连接可能卡在半关闭状态 - K8s Ingress 或云 LB（如 ALB/NLB）通常已有连接空闲超时，Go 层再叠一层容易冲突，优先以 LB 配置为准
Service Mesh 下 Go HTTP 客户端怎么设超时
加了 Istio 或 Linkerd 后，DNS 解析、TLS 握手、mTLS 双向认证、Sidecar 转发都会新增延迟，原生 http.Client 的超时配置很容易失效。
立即学习“go语言免费学习笔记（深入）”；
-
http.Client.Timeout是总耗时上限，必须覆盖 sidecar 往返（建议设为后端 SLA 的 2 倍，如 SLA 是 2s，这里设 4s） -
Transport.DialContext的KeepAlive设为 30s，避免连接池频繁重建（Istio 默认 keepalive 是 30s） - 禁用
Transport.IdleConnTimeout或设为 90s 以上，否则短连接池在 mesh 下容易被 sidecar 主动断开 - 别依赖
context.WithTimeout在 handler 里包整个调用链——sidecar 的重试逻辑会绕过它，导致上游已超时下游还在跑
最麻烦的其实是健康检查路径和 metrics endpoint 的超时配置，它们常被忽略，但一旦超时失败，K8s 就会反复 kill Pod。这类 endpoint 必须走独立的 http.Server 实例，用极短超时（ReadHeaderTimeout: 1s）并关掉所有中间件。
