Go微服务在Kubernetes中卡在CrashLoopBackOff的根本原因是镜像、监听地址、探针三者未对齐：必须监听0.0.0.0而非127.0.0.1，禁用CGO并多阶段构建，selector与template labels须逐字一致，containerPort、探针路径及initialDelaySeconds需严格匹配启动时序。
能跑起来不等于部署成功——90% 的 Go 服务在 Kubernetes 上卡在 CrashLoopBackOff 或 ContainerCreating，根本原因不是代码写错，而是镜像、监听地址、探针三者没对齐。
Go 服务必须监听 0.0.0.0:PORT，不能是 127.0.0.1:PORT
Kubernetes Pod 的网络模型里，localhost 只指向容器自己，Service 流量根本进不来。哪怕 kubectl get pods 显示 Running，curl 任何端口都会超时。
- 错误写法：
http.ListenAndServe("127.0.0.1:8080", nil) - 正确写法：
http.ListenAndServe(":8080", nil)（空 host = 所有接口） - 更稳妥做法：读取环境变量
PORT，拼成":" + os.Getenv("PORT")，再传给ListenAndServe - 记得在 Dockerfile 里加
EXPOSE 8080，虽然它不强制生效，但和 Deployment 中的containerPort对不上时，探针会连不上
Dockerfile 必须用多阶段构建 + CGO_ENABLED=0
Alpine 镜像里没有 glibc，而默认开启 CGO 的 Go 二进制会动态链接它，运行时报错：standard_init_linux.go:228: exec user process caused: no such file or directory。这不是日志缺失，是直接启动失败。
- 构建阶段用
golang:1.22-alpine，关键命令必须带CGO_ENABLED=0 GOOS=linux - 推荐编译参数：
go build -a -ldflags '-s -w -extldflags "-static"' -o main . - 运行阶段优先选
FROM scratch，体积通常 - 如果用了
cgo（比如sqlite3或某些加密库），就得退到alpine:latest并apk add对应依赖，不能再用scratch
livenessProbe 和 readinessProbe 必须分路径、分语义、分超时
Kubernetes 不看进程是否活着，只信 HTTP 状态码。共用一个 /healthz 路径，DB 暂时不可用就会触发 livenessProbe 失败 → 重启 Pod → 加重 DB 压力 → 雪崩。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
-
livenessProbe应该极轻：只返回200，不做 DB 查询、不连下游，路径建议用/livez -
readinessProbe才查真实就绪状态：DBPing()、Redis 是否可写、关键依赖是否响应，路径用/readyz - YAML 中
timeoutSeconds要差异化：liveness设 2 秒，readiness设 10 秒以上，避免滚动更新时误摘流量 - 代码里注册的路径名必须和 YAML 中
httpGet.path完全一致，大小写、斜杠、拼写都不能差
Deployment 的 selector.matchLabels 和 template.labels 必须一字不差
这是 Kubernetes API Server 的硬校验，不是“建议”。多一个空格、大小写不一致、键值顺序不同，都会报错：field is immutable 或 invalid label selector，且后续所有 kubectl apply 都会失败，除非删掉重建。
- 两个地方的 label 必须完全相同，例如都写成
app: go-service，不能一边是app: go-service，另一边是app: GoService -
replicas字段类型是*int32，YAML 里写replicas: 2是合法的（kubectl 会自动转），但如果你用 client-go 编程部署，就得显式调用pointer.Int32(2) - 镜像 tag 别用
:latest，生产环境它等于“无法追踪变更”，K8s 默认不会拉取同名新镜像，得加imagePullPolicy: Always才行
最常被跳过的其实是 SIGTERM 处理：没调 http.Server.Shutdown()，Kubernetes 发出终止信号后，正在处理的请求会被粗暴中断，5xx 错误立刻上升。这不是“优雅”问题，是线上故障根因。
