Go应用K8s部署失败主因是监听地址、探针路径、镜像构建三者未对齐：代码须监听0.0.0.0（如":8080"），禁用CGO并多阶段构建，label必须完全一致，探针路径与状态码需严格匹配。
能跑通 go run main.go 不代表能发布到 Kubernetes——90% 的发布失败源于监听地址、探针路径、镜像构建三者没对齐。
Go 代码必须监听 0.0.0.0:PORT，不能写 127.0.0.1
Kubernetes 中每个 Pod 有独立网络命名空间，localhost 只指向容器自己。kube-proxy 和 Service 流量根本连不上 127.0.0.1:8080。
- 错误写法：
http.ListenAndServe("127.0.0.1:8080", nil)→ Pod 状态是Running，但curl任何地址都超时 - 正确写法：
http.ListenAndServe(":8080", nil)（空 host 默认绑定所有接口） - 更健壮做法：读取环境变量
PORT，拼成":" + os.Getenv("PORT")，再传给http.ListenAndServe - 若用
http.Server，务必先调用net.Listen("tcp", addr)获取 listener，再传给.Serve(lis)，避免探针在 bind 完成前就发起请求
Dockerfile 必须禁用 CGO 并用多阶段构建
Alpine 镜像用 musl libc，而默认开启 CGO 的二进制会尝试链接 glibc，运行时报 standard_init_linux.go:228: exec user process caused: no such file or directory，日志里看不到具体缺哪个库。
- 构建阶段加
CGO_ENABLED=0 GOOS=linux：RUN CGO_ENABLED=0 GOOS=linux go build -a -ldflags="-s -w" -o main . - 运行阶段推荐
FROM scratch或gcr.io/distroless/static-debian12，体积小、无 shell、无法交互式入侵 - 别用
golang:alpine直接当运行镜像——它带编译器和包管理器，纯属冗余且增大攻击面 - 记得加
EXPOSE 8080，虽非强制，但漏掉容易忽略端口意识
Deployment 的 selector.matchLabels 和 template.labels 必须逐字一致
Kubernetes API Server 对 label selector 做硬校验，不是松散匹配。差一个空格、大小写错位、键值顺序不同，都会报 invalid label selector 或 field is immutable，后续 kubectl apply 全部失败，只能删掉重建。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 两边 label 必须完全相同，例如都写成
app: go-service，不能一边是app: go-service，另一边是app: GoService或app: go_service - 多个微服务共用一个 Service 时，各自
template.labels必须统一，否则只有第一个创建的 Pod 被选中 -
replicas字段类型是*int32，YAML 里写replicas: 2是 int 类型，虽常被容忍，但在 client-go 编程部署时会出错
readinessProbe 和 livenessProbe 必须真实存在且参数对齐
Kubernetes 不看进程是否 running，只认探针返回码。没配探针，或路径不存在、端口不对、HTTP 状态码不是 2xx/3xx，Pod 就永远卡在 Ready: 0/1 或反复重启。
- Go 代码里至少暴露两个 handler：
/healthz（基础存活）、/readyz（依赖就绪，比如 DB 连通性检查） -
livenessProbe.httpGet.port和readinessProbe.httpGet.port必须和containerPort一致，不能写成 Service 的port -
initialDelaySeconds得留够时间：Go 启动慢（尤其带 DB 迁移或缓存预热），livenessProbe建议 ≥30s，readinessProbe可设 5–10s - 别用 TCP 探针替代 HTTP 探针——TCP 成功只说明端口开了，不代表业务 ready
最易被忽略的是：健康检查路径在代码里写了，但 YAML 中探针的 path 多了个斜杠（比如写成 /readyz/），或者状态码没显式设置为 200（w.WriteHeader(http.StatusOK) 漏了），这类细节错一点，整个服务就卡死在 Ready=0。
