必须分开暴露/healthz和/readyz两个独立端点：/healthz仅检查进程存活（端口、goroutine、时钟），要求快稳无副作用；/readyz检查服务就绪（DB、Redis等依赖），需异步预热+超时控制，两者均须返回200或503。
Go服务必须暴露/healthz和/readyz两个独立端点
Kubernetes靠这两个探针决定是否转发流量、是否重启或缩容。混用或只暴露一个，会导致新实例还没准备好就被打量流量，或者旧实例被暴力杀掉。
-
/healthz只检查进程是否存活：不查DB、不调下游，返回200即可，超时控制在100ms内 -
/readyz检查真实就绪状态：要验证数据库连接池、Redis连通性、配置加载完成等，失败就拒绝流量 - YAML里
livenessProbe指向/healthz，readinessProbe指向/readyz，且initialDelaySeconds必须大于服务冷启动耗时（比如DB连接+配置拉取共需8秒，这里至少设10）
Shutdown必须带context超时，且超时时间 ≤ terminationGracePeriodSeconds
缩容时Kubernetes先发SIGTERM，等terminationGracePeriodSeconds后强制SIGKILL。Go代码里的Shutdown()如果超时设太长，系统会在你清理完前直接干掉进程。
- 代码中用
context.WithTimeout(context.Background(), 10*time.Second)，YAML里terminationGracePeriodSeconds: 12 -
Shutdown()之后，必须显式关闭DB连接池（db.Close()）、消息消费者（consumer.Close()）、后台ticker（ticker.Stop()） - 别在
Shutdown()回调里写log.Fatal或os.Exit——这会跳过清理逻辑
HPA扩缩容依赖指标采集链路完整，不是加个/metrics就行
光在Go里注册promhttp.Handler()暴露/metrics，不代表HPA能用它。Kubernetes默认只认cpu和memory，自定义指标（如QPS）要走Prometheus + prometheus-adapter + HPA三段链路。
- Go服务暴露
http_requests_total等指标，Prometheus定期抓取 - prometheus-adapter把Prometheus数据转成Kubernetes API可识别的格式（比如
custom.metrics.k8s.io/v1beta1） - HPA配置里用
type: External或type: Pods引用这些指标，不能只写metrics字段就以为生效 - 常见坑：Adapter没部署、RBAC权限没开、HPA targetRef name拼错——查
kubectl describe hpa看Events字段报什么错
无状态是平滑扩缩容的前提，本地缓存和文件写入必须移除
横向扩容的本质是“复制”，只要实例之间有状态耦合，扩再多副本也没用，还可能引发数据不一致。
立即学习“go语言免费学习笔记（深入）”；
- Session、临时文件、内存计数器全部外迁：用Redis存会话，用对象存储存文件，用原子计数器或数据库存统计值
- 避免在
init()里做耗时初始化（如加载大配置、预热缓存），改用lazy load或startup probe配合异步加载 - 所有外部依赖（DB、Redis、gRPC下游）必须支持连接池自动重连，不能因为单次网络抖动就panic退出
resources.requests没填、terminationGracePeriodSeconds比Shutdown超时还短、或者Prometheus Adapter压根没跑起来——这些地方一漏，扩缩容就变成“抖动”而不是“平滑”。 
