Go微服务main入口须监听SIGTERM/SIGINT并调用http.Server.Shutdown()优雅退出，再关闭DB/gRPC等依赖；Dockerfile需CGO_ENABLED=0构建静态二进制；k8s探针应分离/readyz与/livez端点；多阶段构建务必先COPY go.mod/go.sum。
Go 微服务如何正确编写 main 入口以适配容器生命周期
容器化部署下，Go 服务必须能响应 SIGTERM 并优雅退出，否则 Kubernetes 的 preStop 钩子或滚动更新会触发强制 kill，导致请求中断或数据丢失。
关键点不是“启动服务”，而是“可控地结束服务”：
-
http.Server必须显式调用Shutdown()，不能只靠os.Exit() - 监听
os.Interrupt和syscall.SIGTERM两个信号，Kubernetes 默认发的是后者 - 数据库连接池、gRPC 客户端、消息队列消费者等需在
Shutdown()后同步关闭，顺序不能颠倒
示例片段：
srv := &http.Server{Addr: ":8080", Handler: router}
go func() {
if err := srv.ListenAndServe(); err != http.ErrServerClosed {
log.Fatal(err)
}
}()
<!-- 信号捕获与关闭逻辑 -->
quit := make(chan os.Signal, 1)
signal.Notify(quit, os.Interrupt, syscall.SIGTERM)
<!-- 等待信号 -->
<!-- 收到后调用 Shutdown，并等待活跃连接完成 -->
<!-- 最后关闭依赖资源 -->Dockerfile 中 Go 编译为何必须用 CGO_ENABLED=0
不加这个标志，编译出的二进制会动态链接 libc，导致 Alpine 基础镜像无法运行 —— 报错 standard_init_linux.go:228: exec user process caused: no such file or directory 就是典型表现。
立即学习“go语言免费学习笔记（深入）”；
Alpine 使用 musl libc，而默认 Go 编译（CGO_ENABLED=1）依赖 glibc；即使你用 Ubuntu 基础镜像，也建议关掉 cgo，理由更实际：
- 镜像体积减少 30–50MB（无
/usr/lib/x86_64-linux-gnu/libc.so.6等） - 避免因基础镜像升级 libc 版本引发的兼容性抖动
- 静态二进制可直接拷贝进 scratch 镜像，最小化攻击面
正确写法：
FROM golang:1.22-alpine AS builder WORKDIR /app COPY go.mod go.sum ./ RUN go mod download COPY . . RUN CGO_ENABLED=0 GOOS=linux go build -a -ldflags '-extldflags "-static"' -o /usr/local/bin/service . <p>FROM scratch COPY --from=builder /usr/local/bin/service /service EXPOSE 8080 CMD ["/service"]
Kubernetes 中 livenessProbe 和 readinessProbe 该用哪个 HTTP 端点
别用 /health 一把梭。Go 服务里这两个探针应指向语义明确、开销隔离的 handler：
-
readinessProbe：检查服务是否准备好接收流量，例如 DB 连接池是否就绪、gRPC 后端是否连通、本地缓存是否 warm up 完成 —— 用/readyz，超时设为 1–3 秒，失败阈值failureThreshold: 3 -
livenessProbe：判断进程是否卡死或陷入不可恢复状态，例如 goroutine 泄漏、内存持续上涨、主事件循环停滞 —— 用/livez，建议走内存/协程数等轻量指标，避免查 DB 或远程依赖
错误做法：livenessProbe 调用 /health 并查数据库，一旦 DB 慢了就反复重启 Pod，形成雪崩。
Go 内置支持可参考 k8s.io/client-go/tools/leaderelection 的健康检查模式，或直接用 net/http/pprof 的 /debug/pprof/goroutine?debug=1 做简易存活判断（仅限开发）。
Go Module 依赖在多阶段构建中为何常出现 cannot find module providing package
根本原因是 go build 在 builder 阶段找不到 go.mod 或路径不对，常见于以下场景：
- Dockerfile 中
COPY . .前没先COPY go.mod go.sum .，导致go mod download时模块信息为空 - 项目含子模块（如
cmd/api），但go build命令路径写成go build -o bin/api ./cmd/api，而当前工作目录不在项目根目录 - 使用了 replace 指向本地路径（如
replace example.com/lib => ../lib），但 multi-stage 构建时../lib在 builder 镜像中不存在
解决方案只有两条铁律：
- 始终在项目根目录执行构建，且
COPY go.mod go.sum必须在COPY . .之前 - 本地 replace 一律改用
replace example.com/lib => ./local-lib，并COPY local-lib ./local-lib
验证方式：在 Dockerfile builder 阶段末尾加 RUN go list -m all | head -5，确认依赖列表正常输出。
Go 微服务容器化真正的难点不在语法，而在把“进程模型”和“容器模型”对齐：一个 Go 程序默认只管自己，但 Kubernetes 要求它理解 readiness、liveness、terminationGracePeriodSeconds、initContainer 依赖顺序这些外部契约 —— 这些没法靠 go run 测试出来，必须在 CI 阶段跑真实 kind 或 minikube 集群验证信号传递和探针行为。
