Kubernetes中Go服务探针必须物理隔离：livenessProbe走独立端口（如:8081）/livez，仅返回200且无依赖；readinessProbe走业务端口（如:8080）/readyz，检查DB等真实就绪条件；两者timeoutSeconds需不同，且须用原生http.ServeMux单独暴露、异步启动，并正确处理SIGTERM与Shutdown。
Go服务在 Kubernetes 里跑不稳、扩缩容失效、健康检查总失败？不是框架选得不对，而是集成方式没对齐 Kubernetes 的运行模型。
livenessProbe 和 readinessProbe 必须走不同路径和端口
共用 /healthz 是最常见误配：Kubernetes 会因 DB 暂时不可用触发 liveness 失败 → Pod 重启 → 加重下游压力 → 雪崩。必须物理隔离两个探针的 HTTP 端点与逻辑。
-
livenessProbe应指向独立端口（如:8081）下的/livez，只返回200 OK，不做任何依赖校验 -
readinessProbe指向业务端口（如:8080）下的/readyz，需检查 DB 连接、gRPC 后端连通性等真实就绪条件 - Deployment 中两个探针的
timeoutSeconds必须不同：liveness建议设为1–3，readiness设为10+，避免滚动更新时误摘流量 - 不要复用 Gin/Echo/Chi 的路由引擎处理探针——它们自带中间件链、panic 恢复和超时控制，干扰探针语义
用原生 http.ServeMux 单独暴露探针端点
框架路由外起一个干净的 http.Server，绕过所有中间件、日志、鉴权、recover，确保探针响应确定、低延迟、无副作用。
- 示例代码中，
probeMux := http.NewServeMux()是唯一依赖，不引入任何第三方 router -
probeMux.HandleFunc("/livez", func(w http.ResponseWriter, r *http.Request) { w.WriteHeader(http.StatusOK) })不查 DB、不打日志、不调外部服务 - 必须用
go http.ListenAndServe(":8081", probeMux)异步启动，且监听地址不能与主服务端口冲突 - 若用
net/http以外的库（如 fasthttp），需确认其Server.Shutdown()行为是否兼容 SIGTERM 流程
main 函数里必须监听 SIGTERM 并调用 Shutdown()
不这么做，Kubernetes 发出终止信号后，Go 进程会立刻退出，正在处理的请求被强制中断，用户收到 502/504 或连接重置。
Golang Samber Hot
下载
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
立即学习“go语言免费学习笔记（深入）”；
- 用
signal.Notify(c, os.Interrupt, syscall.SIGTERM)捕获信号，不能只靠defer或os.Exit() -
server.Shutdown()必须传入带超时的context，超时值应略大于最长业务请求耗时（如30s） - Shutdown 返回后，再关闭 DB 连接池、gRPC 客户端、消息消费者等依赖；顺序颠倒会导致资源泄漏或 panic
- 务必在
http.Server初始化时设置ReadTimeout和WriteTimeout，防止慢连接拖垮整个 server
镜像构建必须加 CGO_ENABLED=0 且用 scratch 基础镜像
Alpine 镜像下报 standard_init_linux.go:228: exec user process caused: no such file or directory，本质是 musl libc 与 glibc 链接冲突，不是权限或路径问题。
- Dockerfile 构建阶段必须显式写
RUN CGO_ENABLED=0 GOOS=linux go build -ldflags="-s -w" -o main .，不能只设环境变量 - 运行阶段优先用
FROM scratch，而非alpine：体积更小（通常 - 若需调试能力（如
strace或curl），可用distroless/static替代scratch，但别回退到alpine - 多阶段构建中，
COPY --from=builder只复制二进制，不复制go.mod、源码、测试文件等无关内容
真正难的不是写完探针或编译镜像，而是在 Deployment YAML、Dockerfile、Go main 函数、HTTP server 初始化这四个地方保持行为一致——任意一处脱节，都会导致“服务看起来在跑，实际已不可用”。
