go服务在k8s运行失败主因是镜像路径错、监听端口不匹配、探针时机过早、配置挂载错误；须逐项验证：二进制位置、log打印的监听地址、initialdelayseconds≥冷启时间、configmap/secret挂载路径与代码读取一致。
镜像启动就报 exec: "server": executable file not found in $PATH
根本不是 Go 编译失败，而是容器运行时找不到二进制文件。Docker 镜像里 CMD 或 ENTRYPOINT 指定的路径和实际文件位置不一致。
- 检查
Dockerfile中WORKDIR是否设为/app，且COPY后二进制确实落在/app/server - 别用
CMD ["go", "run", "main.go"]—— 生产镜像不能带 Go 环境 - 交叉编译必须加
CGO_ENABLED=0 GOOS=linux go build -a -ldflags="-w -s" -o /app/server ./cmd/server - 验证方式：运行
docker run --rm -it your-image:tag sh -c 'ls -l /app/server && /app/server --help'，能看到帮助输出才算过关
Pod 一直 CrashLoopBackOff，但日志空或只有半行
Go 进程可能在打印“started”后几秒内因配置/依赖失败而退出，当前容器日志已清空，必须看上一轮崩溃记录。
Golang Google Wire
下载
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
- 用
kubectl logs <pod-name> --previous</pod-name>查真实错误，不是kubectl logs - 高频真凶：
ConfigMap挂载路径错（比如挂到/etc/config，但代码读/config.yaml）、Secret未注入导致数据库密码为空、环境变量名拼写错误（DATABASE_URL写成DB_URL） - 探针路径也常踩坑：
readinessProbe.httpGet.path: /healthz，但 Go 服务只暴露/health，HTTP handler 返回 404 → K8s 当作失败 → 杀 Pod
Service 流量进不来，curl 超时或 connection refused
containerPort 不是端口转发开关，它只是个标签；真正决定流量能否抵达进程的，是 Service 的 targetPort 是否等于 Go 程序实际监听的端口。
- Go 启动日志必须明确打印监听地址，例如
log.Printf("server started on :8080")—— 这是唯一可信依据 - Deployment 中
containerPort: 8080建议和监听端口严格一致（虽非强制，但避免团队误读） - Service 的
targetPort: 8080必须等于上面那行日志里的端口，type: ClusterIP或NodePort都不影响这个匹配逻辑 - 别碰
hostPort—— 它绑宿主机端口，在 K8s 里基本不用，还容易冲突
滚动更新卡住，新 Pod 反复被删
不是健康检查写错了，而是 initialDelaySeconds 设得太小，应用还没初始化完，探针就开杀。
- Go 默认 HTTP handler 在未就绪时直接返回 503，K8s 把它当失败处理
- 冷启动耗时 8 秒？那就把
livenessProbe.initialDelaySeconds设为至少 12 秒，readinessProbe同理 - 别信 “本地启动快”，容器里 DNS 解析、ConfigMap 挂载、依赖服务连接都更慢
- 如果用了
ConfigMap热更新，注意默认是subPath挂载，改配置不会触发文件更新事件 —— Go 应用得自己轮询或监听inotify
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
