Go微服务动态扩容核心在于Kubernetes调度适配，而非代码加go关键字；需实现无状态、独立健康/就绪探针（/healthz仅进程存活，/readyz检查DB等依赖）、正确信号处理与反注册、端口配置标准化及单实例性能优化。
Go 微服务扩展集群规模，不是靠改代码加 go 关键字，而是让每个实例能被 Kubernetes 安全、稳定、可感知地调度起来。核心是“无状态 + 可探活 + 可注销 + 可指标化”。
/healthz 和 /readyz 必须分开，且逻辑不能混用
很多团队把两个端点写成同一个 handler，结果缩容时流量还在打进来，或者扩容后 Pod 卡在 ContainerCreating 状态迟迟不就绪。
-
/healthz只检查进程是否存活：不查 DB、不调下游、不碰 Redis，只返回200和{"status":"ok"} -
/readyz才检查依赖：比如db.PingContext()、redis.Ping()、gRPC server 是否已启动、配置是否加载完成 - Kubernetes 的
readinessProbe必须指向/readyz，否则新 Pod 会立刻收流量，但 DB 连接还没建好 - 响应超时建议设为
1s，失败重试间隔5s，避免探针拖慢整个滚动更新
扩容前先确认 net.Listen 没被端口冲突卡住
Go 1.11+ 默认启用 SO_REUSEPORT，但如果你在容器里硬编码了 :8080，又没设 HOST=0.0.0.0，多个副本可能抢不到端口，日志里只报 listen tcp :8080: bind: address already in use。
- 监听地址必须是
0.0.0.0:$PORT，不能是127.0.0.1:$PORT或空字符串 - 用环境变量传端口：
PORT=${PORT:-8080}，并在http.ListenAndServe(fmt.Sprintf(":%s", os.Getenv("PORT")), r)中使用 - 在 Dockerfile 里加
EXPOSE $PORT，KubernetescontainerPort要和它一致 - 如果用了 gRPC，同样要确保
grpc.NewServer()后的lis, _ := net.Listen("tcp", "0.0.0.0:"+port)
缩容时反注册失败会导致僵尸实例
Pod 收到 SIGTERM 后直接退出，没调服务发现中心的注销接口，旧地址还留在 Consul/Nacos/etcd 里，请求持续打过去，超时或 5xx 暴增。
立即学习“go语言免费学习笔记（深入）”；
- 必须用
os.Interrupt和syscall.SIGTERM双捕获（K8s 默认发 SIGTERM，本地测试常只发 SIGINT） - 注销逻辑放在
defer里不安全——http.Server.Shutdown()前就要反注册，否则 LB 已剔除你，但注册中心还留着你 - 注销 API 调用要带超时（建议
3s），失败打日志但不阻塞退出：log.Printf("deregister failed: %v", err) - 如果用 etcd，注销前先删 key；用 Nacos，调
/nacos/v1/ns/instance的 DELETE 接口
横向扩容无效时，先看单实例有没有内部瓶颈
加到 10 个 Pod，QPS 没涨，CPU 却飙到 90%，大概率不是缺实例，是单个 Go 进程自己卡住了。
- 全局
sync.Mutex保护计数器？换成sync/atomic或分片计数 - 用
map做内存缓存 +sync.RWMutex？高并发下锁争用严重，该上 Redis -
*sql.DB连接池没调SetMaxOpenConns和SetMaxIdleConns？所有 Pod 共享同一连接池上限，一卡全卡 - GC 频次异常高？用
runtime.ReadMemStats检查NumGC，可能是对象频繁分配没复用
真正难的不是起 10 个实例，而是让第 10 个实例和第 1 个一样快、一样稳、一样能干净退出。很多问题不在 Kubernetes YAML 里，而在 main.go 的那几行 signal 处理和 defer 调用顺序中。
