Go服务需实现/healthz和/readyz健康检查端点，避免依赖外部资源；滚动更新时须监听SIGTERM并用srv.Shutdown()优雅退出，所有goroutine应基于context.Context主动退出。
Go语言本身不直接参与“编排”，它生成的服务二进制文件是被Kubernetes或Docker Compose这类编排工具调度的对象；真正起作用的是你如何设计服务行为、暴露接口、响应健康检查，以及是否适配编排系统的预期。
Go服务必须实现/healthz端点才能被Kubernetes正确探活
Kubernetes的livenessProbe和readinessProbe默认通过HTTP GET请求检测服务状态，如果Go服务没暴露标准健康检查接口，Pod会反复重启或无法进入Ready状态。
- 不要只写
http.HandleFunc("/healthz", ...)然后返回200——需确保该 handler 不依赖数据库连接、外部缓存或未初始化的全局资源 - 推荐用
net/http自带的http.ServeMux注册，避免第三方路由库在probe路径上做中间件拦截（比如Auth中间件可能拦掉/healthz） - 生产环境建议区分
/healthz（仅检查进程存活）和/readyz（检查依赖就绪），后者可调用db.PingContext()或redis.Ping()
goroutine泄漏会导致Kubernetes滚动更新卡住
滚动更新时，Kubernetes先启动新Pod，等其readinessProbe通过后，再终止旧Pod。若旧服务里有未退出的goroutine（比如未关闭的time.Ticker、未close()的channel监听、或阻塞在http.Serve()上的server），SIGTERM信号发过去后进程不会退出，导致更新超时失败。
- 务必在
main()中监听os.Interrupt和syscall.SIGTERM，调用srv.Shutdown()而非srv.Close() - 所有长期运行的goroutine都应接收
context.Context并主动检查ctx.Done()，例如：for { select { case - 使用
pprof在容器内暴露/debug/pprof/goroutine?debug=2，上线前人工确认goroutine数量稳定
Docker镜像体积和启动速度直接受Go构建参数影响
静态编译的Go二进制虽小，但默认包含调试符号和DWARF信息，镜像层会多出10–15MB；且未strip的二进制启动慢200–400ms，在Kubernetes大量Pod并发启动时明显拖慢整体就绪时间。
立即学习“go语言免费学习笔记（深入）”；
- 构建命令必须加
-ldflags="-s -w"：去掉符号表和调试信息 - 多阶段构建中，build stage用
golang:1.23-alpine，final stage用scratch或alpine:latest，避免带libc冗余 - 禁用CGO（
CGO_ENABLED=0）——除非你明确依赖C库（如sqlite3），否则它会让二进制变大且引入libc兼容性风险
最常被忽略的不是代码怎么写，而是Go服务在容器生命周期里如何与Kubernetes“对话”：它是否及时响应SIGTERM，是否诚实报告就绪状态，是否在探针路径上保持轻量。这些细节不写在.gin或.gRPC文档里，却决定编排系统能否真正信任你的服务。
