多个Go服务共用同一Service时，selector必须匹配Pod的label而非Deployment名或镜像名；需统一label键值（如app: my-go-service），且Deployment中template.labels与spec.selector.matchLabels须严格一致。
多个Golang服务共用同一个Service怎么配
Service 的 selector 不认 Deployment 名、不认镜像名，只认 Pod 上的 label。两个不同 Deployment 想被同一个 Service 转发，label 键值必须完全一致。
- 统一约定一个 label 键，比如都用
app: my-go-service，Service 的selector就写app: my-go-service - Deployment 中的
template.metadata.labels和spec.selector.matchLabels必须严格一致，否则报错Invalid value: "xxx": field is immutable - 别把
containerPort和targetPort搞反：前者是容器里监听的端口（Go 代码里写的:8080），后者是 Service 转发到该端口的值，通常和containerPort相同 - 多个服务共用 Service 时，
port（Service 对外暴露端口）建议设为固定值（如80或8080），避免客户端硬编码变动端口
Deployment YAML里哪些字段不能漏
本地 go run main.go 能通，但 Pod 卡在 CrashLoopBackOff 或 ContainerCreating，八成是这几个字段没填或填错。
-
spec.containers[].ports[].containerPort必须和 Go 代码中http.ListenAndServe(":8080", nil)的端口一致 - 必须加
livenessProbe和readinessProbe，哪怕只是 HTTP GET/healthz；不加的话 K8s 不知道服务是否真就绪，会反复重启 -
image别用localhost:5000/myapp这种地址，除非你明确设了imagePullPolicy: Never，否则拉不到镜像 - Go 代码必须监听
0.0.0.0:8080，不能只写127.0.0.1:8080——Pod IP 是网卡地址，K8s 流量进不来
健康探针路径不生效的常见原因
YAML 里写了 httpGet.path: /healthz，但探针一直 404，不是 K8s 配置问题，而是 Go 服务本身没注册对应路由。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- Go 代码里必须显式注册
http.HandleFunc("/healthz", ...)，路径名要和 YAML 中httpGet.path完全一致（大小写、斜杠都不能差） -
/healthz应只返回 200，不做 DB 查询、不连下游——它只回答“进程还活着吗” -
/readyz可查 DB、Redis 等依赖，但超时必须短（建议timeoutSeconds: 10），否则探针失败导致 Pod 被反复踢出流量 - 如果用了 Gin/Echo 等框架，别忘了调用
router.Run(":8080")或等价阻塞逻辑，否则 main 函数退出，容器立刻终止
多阶段 Dockerfile 怎么写才安全轻量
镜像太大不只是“占空间”，它直接引发 ImagePullBackOff、节点磁盘爆满、CI 流水线卡住。静态二进制 + scratch 是底线。
立即学习“go语言免费学习笔记（深入）”；
- 构建阶段用
golang:1.22-alpine，关键命令是：RUN CGO_ENABLED=0 GOOS=linux go build -a -ldflags '-extldflags "-static"' -o main . - 运行阶段必须用
FROM scratch或alpine:latest；若用了 cgo（比如 sqlite3），只能选 alpine 并apk add依赖 - 入口命令必须是
CMD ["/main"]，不是go run main.go——后者会把整个 Go 工具链打进镜像 - 加上
USER 65532:65532以非 root 用户运行，避免容器逃逸后获得高权限
