Go服务需暴露/healthz和/metrics端点、避免goroutine泄漏、合理设min/maxReplicas，并用请求级指标替代CPU进行HPA扩缩容。
Go 服务本身不实现自动扩缩容，Kubernetes 的 HorizontalPodAutoscaler（HPA）才是执行者；你的 Go 程序只需暴露正确端点、拒绝无效指标干扰、并能安全退出，HPA 才能稳定工作。
Go 服务必须暴露 /healthz 和 /metrics 端点
HPA 不直接调用你的业务逻辑，但它依赖 K8s 探针和监控系统持续读取状态。缺一不可：
-
/healthz必须监听在0.0.0.0:8080（不能是127.0.0.1），否则 readiness/liveness 探针失败，新 Pod 无法进入 Ready 状态 -
/metrics需返回 Prometheus 格式文本（如用promhttp.Handler()），且至少包含http_requests_total这类可聚合的 counter 指标 - 若用 Gin/Echo 等框架，别把
/metrics注册到带中间件的路由组里——日志、鉴权等中间件会污染指标采集，应单独挂到http.DefaultServeMux或独立http.ServeMux
HPA 配置里别只写 CPU utilization
CPU 利用率对 Go 服务响应慢、误判多：GC 暂停会让 CPU 瞬时飙升，但实际请求没增加；高并发下 goroutine 调度开销小，CPU 可能还不到 30%，QPS 却已打满。真实配置应优先用请求级指标：
- 用
averageValue替代averageUtilization，比如设averageValue: "80"表示目标 QPS 是 80，单位由 Prometheus Adapter 解析决定 - 对应 Prometheus 查询必须用
rate(http_requests_total{job="my-go-app"}[2m])，[1m]太短，容易被偶发请求抖动触发误扩容 - HPA 的
behavior字段必须显式配scaleDown.stabilizationWindowSeconds: 300，否则流量回落一点就立刻缩容，旧 Pod 还没完全退出，新请求就可能 503
Go 代码里 goroutine 泄漏会让 HPA 彻底失灵
HPA 依赖指标反映真实负载。如果 Go 服务里有常驻 goroutine（比如一个忘记检查 ctx.Done() 的轮询任务），它会在 Pod 生命周期内持续上报“活跃”，导致 go_goroutines 指标缓慢上涨，而 http_requests_total 却几乎不动——HPA 看到的是“资源占用高但无请求”，可能错误地持续扩容，或缩容时卡在最后一个实例上死循环。
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
立即学习“go语言免费学习笔记（深入）”；
- 所有后台 goroutine 必须接收 context 并响应取消，尤其是数据库连接池、消息消费者、定时器等
- 在
Shutdown()前加一段等待逻辑：time.Sleep(100 * time.Millisecond)，确保 goroutine 退出信号已传播 - 上线前用
curl -s http://localhost:8080/metrics | grep go_goroutines观察空载时是否稳定（通常 8–15 个是合理范围）
minReplicas 和 maxReplicas 不是随便写的数字
这两个值不是性能参数，而是系统边界约束：
-
minReplicas: 2是底线——单实例故障时，服务不可用；低于 2 就失去基本可用性 -
maxReplicas要结合后端瓶颈定：比如 PostgreSQL 连接池只有 100，每个 Go 实例默认建 10 个连接，那maxReplicas就不能超过 10；再比如第三方 API 限流 1000 QPS，单实例处理能力 120 QPS，理论最大就是 8 - 如果用了 KEDA 监听 Kafka lag，
maxReplicas还得预留 buffer 应对突发积压，但 buffer 太大会拖慢缩容速度——这需要压测验证，不能靠估算
最易被忽略的一点：HPA 的指标采样周期（默认 15 秒）和你 Prometheus 抓取间隔（比如 30 秒）不一致时，averageValue 会频繁跳变；务必让 scrape_interval ≤ HPA sync-period（可通过 kubectl get hpa -o yaml 查看），否则扩缩决策永远滞后于真实流量。
