应使用多阶段构建+静态编译+GOMEMLIMIT+端口就绪检测：第一阶段golang:1.22-alpine编译，第二阶段scratch或distroless镜像，加-ldflags="-s -w -buildmode=pie"、GOCACHE=off、CGO_ENABLED=0，ENTRYPOINT["/main"]；启动前net.Listen获取listener再Serve；设GOMEMLIMIT为cgroup limit的80%；liveness用/healthz、readiness用/readyz并检查真实依赖；Service targetPort须与程序监听端口一致。
Go 微服务如何写好 Dockerfile 才不踩内存和启动失败的坑
直接用 FROM golang:alpine 编译再运行，大概率在 Kubernetes 里被 OOMKilled 或健康检查失败。根本原因是默认镜像带完整 Go 环境和 C 依赖，而生产容器只需要静态二进制文件。
- 必须用多阶段构建：第一阶段用
golang:1.22-alpine编译，第二阶段用scratch或gcr.io/distroless/static:nonroot - 编译时加
-ldflags="-s -w -buildmode=pie"去除调试信息、禁用动态链接、启用位置无关可执行文件 - 显式设置
GOCACHE=off和CGO_ENABLED=0，避免意外引入 libc 依赖 - 入口命令别写
./main，改用ENTRYPOINT ["/main"]，确保 PID 1 是你的服务进程（否则信号转发异常）
为什么 Kubernetes 中 Go 服务经常 liveness probe 失败
不是代码没写好，而是 probe 配置和 Go HTTP server 启动时机不匹配。Go 的 http.ListenAndServe 是阻塞调用，但 readiness/liveness 探针在容器启动后立刻发起请求，此时 server 还没真正 bind 成功。
- 不要依赖“容器启动即就绪”，在 main 函数里加
time.Sleep(100 * time.Millisecond)不可靠，应使用监听端口就绪检测 - 推荐用
net.Listen("tcp", ":8080")先获取 listener，再传给&http.Server{Addr: ..., Handler: ...}.Serve(lis) - liveness 探针建议指向
/healthz，只返回 200；readiness 指向/readyz，需检查数据库连接、gRPC 依赖等真实依赖项 - Kubernetes 默认
initialDelaySeconds: 0，至少设为5，failureThreshold别小于3，防止短暂 GC STW 导致误杀
Go 微服务在 K8s 里怎么限制内存才不被突然 kill
Go runtime 的内存管理机制和 Linux cgroup 有冲突：即使设置了 resources.limits.memory，Go 的 runtime.GC 可能仍尝试申请超过 limit 的堆空间，触发 OOMKilled。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 务必同时设置
resources.limits.memory和resources.requests.memory，且 requests ≤ limits，否则调度器可能把 Pod 分配到内存不足节点 - 在 Go 程序启动时读取
/sys/fs/cgroup/memory/memory.limit_in_bytes（K8s 1.20+ 默认挂载），用它设置GOMEMLIMIT环境变量，例如：GOMEMLIMIT=80%$(cat /sys/fs/cgroup/memory/memory.limit_in_bytes) - 避免用
sync.Pool缓存大对象，Pool 在 GC 时不清空，容易导致内存长期驻留超限 - 用
pprof暴露/debug/pprof/heap，定期抓取分析，重点关注inuse_space和alloc_space差值是否持续扩大
Service 和 Ingress 怎么配才让 Go 微服务真正可访问
本地 curl localhost:8080 能通，但 K8s 里 ClusterIP Service 访问失败，90% 是端口映射或协议配置错。
立即学习“go语言免费学习笔记（深入）”；
- Service 的
targetPort必须和 Go 程序实际监听的端口一致（比如http.ListenAndServe(":8080", nil)→targetPort: 8080），不是 containerPort - Deployment 的
container.port名称要和 Service 的targetPort字符串匹配（如果用 name 而非 number），否则 kube-proxy 不生效 - Ingress controller（如 nginx-ingress）默认不支持 HTTP/2，若 Go 服务启用了
http2.ConfigureServer，需在 Ingress annotation 加nginx.ingress.kubernetes.io/ssl-redirect: "false"并确认 TLS 终止位置 - 跨 namespace 调用时，Service DNS 格式是
<service-name>.<namespace>.svc.cluster.local</namespace></service-name>，硬编码localhost或127.0.0.1必然失败
Go 微服务容器化最易被忽略的点，其实是 GOMEMLIMIT 和 cgroup v2 的兼容性——K8s 1.24+ 默认启用 cgroup v2，旧版 Go（go version 和集群 cgroup 版本匹配。
