go微服务在docker中启动失败，主因是未设cgo_enabled=0导致alpine镜像缺libc、未监听sigterm致k8s强杀、健康探针未分离引发误重启；须静态编译、优雅关闭、多阶段构建及合理probe配置。
Go 微服务在 Docker 中跑不起来，八成是 CGO_ENABLED=0 没设，或者信号没监听导致 Kubernetes 强杀；镜像体积大、启动失败、健康探针超时，基本都卡在这几个点上。
CGO_ENABLED=0 必须加，否则 Alpine 镜像直接报错
默认 go build 会启用 cgo，生成的二进制依赖系统 libc（glibc）。而 Alpine 用的是 musl libc，运行时找不到 libc.so.6，就会抛出 standard_init_linux.go:228: exec user process caused: no such file or directory。
-
CGO_ENABLED=0是硬性要求，不能省；本地 macOS/Windows 构建也得加，否则跨平台失效 -
GOOS=linux同样不能漏，尤其 CI 环境里容易忽略 - 静态链接更稳妥：加
-ldflags '-extldflags "-static"'，避免 runtime 动态加载失败 - 用
scratch或distroless镜像时，连ca-certificates都要手动注入，Alpine 的apk add反而更省心
main 入口必须监听 SIGTERM，否则 K8s 滚动更新丢请求
Kubernetes 默认发 SIGTERM 触发 preStop，如果 Go 程序没捕获，会等 30 秒超时后强制 KILL —— 此时活跃 HTTP 连接被断开，DB 事务可能未提交，gRPC 流中断。
- 只监听
os.Interrupt不够，必须显式加syscall.SIGTERM -
http.Server.Shutdown()要传 context，建议带 timeout（如 10s），避免无限等待 - 关闭顺序很重要：先
Shutdown()HTTP Server，再关 DB 连接池、gRPC Client、消息队列消费者 - 别在
Shutdown()前调os.Exit()，那等于放弃优雅退出
Dockerfile 多阶段构建，别把 go toolchain 塞进最终镜像
用 FROM golang:alpine 直接 RUN go build 再 CMD，最终镜像会含整个 Go 编译器和源码，体积动辄 400MB+，毫无必要。
- 第一阶段用
golang:1.22-alpine AS builder，只负责编译 -
COPY go.mod go.sum放在COPY . .前，利用 Docker layer cache 加速 - 第二阶段选
alpine:latest或gcr.io/distroless/static-debian11，只 COPY 二进制 -
EXPOSE 8080是文档作用，真正生效靠程序绑定0.0.0.0:8080+docker run -p
K8s probe 端点要分离，/livez 和 /readyz 不能共用一个 handler
把所有健康检查都打到 /healthz，会导致 liveness 探针误杀——比如 DB 临时不可用，/readyz 应该返回 503，但 /livez 仍应返回 200，否则 Pod 被反复重启。
-
/livez只检查进程存活（如能否响应 HTTP），不查下游依赖 -
/readyz必须校验 DB 连接、Redis、关键外部 API 是否可用 - 探针
--start-period=30s给初始化留时间，尤其连 DB 或加载配置耗时场景 - Alpine 镜像没
curl，HEALTHCHECK CMD wget --spider http://localhost:8080/readyz更可靠
最常被跳过的其实是 shutdown 顺序和 probe 分离——前者导致数据丢失难复现，后者让故障定位变得模糊。动手前先确认这两项，比调参数有用得多。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
