云原生平台不直接提升Go应用可扩展性，而是提供可靠自动扩缩容的基础设施；Go应用须无状态、支持并发，并实现/healthz（检查内存/goroutine）和/readyz（检查DB等外部依赖）接口，二者不可复用。
云原生平台本身不直接“提升” Go 应用的可扩展性，它提供的是让 Go 程序能被可靠、自动、按需扩缩容的基础设施能力。Go 代码写得是否支持并发、是否无状态、是否健康可探测，才是前提。
Go 应用必须实现 /healthz 和 /readyz 接口
Kubernetes 依赖这两个端点判断 Pod 是否可接收流量（/readyz）和是否运行正常（/healthz）。缺一不可，否则滚动更新或自动扩缩容会卡住或误杀实例。
-
/healthz应只检查进程内核心依赖（如内存、goroutine 数量），避免调用外部服务；返回200即可 -
/readyz必须检查关键外部依赖（如数据库连接池、Redis 连接），任一失败就返回503 - 不要复用同一个 handler ——
/healthz可高频轮询，/readyz在扩缩容前才触发，语义和响应要求不同
func main() {
mux := http.NewServeMux()
mux.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) {
w.WriteHeader(http.StatusOK)
w.Write([]byte("ok"))
})
mux.HandleFunc("/readyz", func(w http.ResponseWriter, r *http.Request) {
if !db.PingContext(r.Context()) {
http.Error(w, "db unreachable", http.StatusServiceUnavailable)
return
}
w.WriteHeader(http.StatusOK)
w.Write([]byte("ready"))
})
http.ListenAndServe(":8080", mux)
}
用 sync.Pool + 预分配缓冲区降低 GC 压力
高并发下频繁分配小对象（如 JSON 解析的 []byte、临时 struct）会显著抬高 GC 频率，导致 CPU 毛刺，影响 HPA（Horizontal Pod Autoscaler）对真实负载的判断。K8s 扩容依据的是 CPU/内存指标，GC 尖峰可能误触发扩容。
- 对固定生命周期的对象（如 HTTP 请求中的 buffer、proto message 实例）优先用
sync.Pool - HTTP handler 中避免在循环里用
make([]byte, n)，改用pool.Get().([]byte)复用 - JSON 解析时用
json.Unmarshal的预分配切片参数，而非每次都 new struct
配置必须外置：别硬编码 port、database_url 或 log_level
云原生环境要求“一次构建、多环境部署”。硬编码配置会让镜像无法复用，破坏声明式交付流程，也阻碍基于标签的灰度扩缩（例如只对 env=staging 的副本做 CPU 限流）。
立即学习“go语言免费学习笔记（深入）”；
- 所有配置项通过环境变量读取：
os.Getenv("DB_URL")，配合godotenv仅用于本地开发 - 监听端口必须从
PORT环境变量读（K8s Service 默认注入），而非写死:8080 - 日志级别设为
INFO默认，用LOG_LEVEL控制，避免在生产镜像里留DEBUG日志拖慢吞吐
HPA 依赖的指标不能只看 CPU：要暴露自定义指标如 http_requests_total
K8s 默认 HPA 基于 CPU 利用率扩缩，但 Go 服务常因 goroutine 阻塞、锁竞争或 DB 等待而 CPU 很低却已不可用——此时 CPU 指标失效，HPA 不会扩容，请求持续堆积。
- 用
prometheus/client_golang暴露http_requests_total{code="200",method="POST"}等指标 - 配合
prometheus-adapter把该指标注册为 K8s 自定义指标（如requests_per_second） - HPA 配置中引用该指标，阈值设为每秒请求数（QPS），比 CPU 更贴近业务真实压力
真正难的不是写 Go 代码，而是让每个 handler 不偷偷持有全局状态、不忽略 context 超时、不在 defer 里做阻塞操作——这些细节决定你的服务在 K8s 里是稳定伸缩，还是扩了又崩、崩了再扩。
