必须用多阶段构建：单阶段会将Go编译器等全塞入镜像致800MB+，拖慢部署、扩大攻击面；运行阶段须用alpine或distroless等最小镜像，禁装包管理器，且需设CGO_ENABLED=0和GOOS=linux确保静态编译。
Go 应用在 Kubernetes 上跑不起来，八成是镜像没做对——不是体积太大，就是运行时缺东西，或者根本没暴露端口。多阶段编译不是可选项，是必选项。
为什么必须用多阶段构建 Dockerfile
单阶段构建会把 Go 编译器、SDK、测试工具链全塞进最终镜像，导致镜像动辄 800MB+，既拖慢部署，又放大攻击面。Kubernetes 调度 Pod 时拉镜像失败、启动超时、OOM kill，很多都源于此。
-
FROM golang:1.21阶段只负责go build，不参与运行 - 运行阶段必须用
alpine:latest或gcr.io/distroless/static-debian12这类无包管理器、无 shell 的最小基础镜像 - 别在运行镜像里装
apk add或apt-get——静态二进制不需要动态库，装了反而留后门
CGO_ENABLED=0 和 GOOS=linux 必须显式设置
默认开启 CGO 会导致编译产物依赖 libc，在 Alpine 或 distroless 镜像里直接报 no such file or directory 错误。这个错误不会在构建时报，而是在容器 docker run 或 Kubernetes Pod 启动时才暴露。
- 构建命令必须写全：
CGO_ENABLED=0 GOOS=linux go build -a -ldflags="-s -w" -o main ./cmd/api -
-s -w去除调试符号，能再压掉 30%~50% 二进制体积 - 如果用了
cgo特性（比如调用 OpenSSL 或 SQLite），就得换基础镜像为debian:slim，并手动apt install对应库——但这是退让，不是推荐路径
Kubernetes 中的 containerPort 和就绪探针必须匹配实际监听端口
很多 Go 服务从环境变量读端口（如 os.Getenv("PORT")），但 Deployment 里写的 containerPort: 8080 和实际监听端口不一致，会导致 Service 流量打不到 Pod，kubectl get pods 显示 Running，但 curl 一直 Connection refused。
立即学习“go语言免费学习笔记（深入）”；
- Go 代码中监听端口要和 YAML 中
containerPort严格一致，或统一用8080硬编码（开发期） -
readinessProbe的httpGet.port必须指向containerPort，不能写成字符串"8080"，得是数字8080（YAML 解析规则） - Probe 路径建议用
/healthz，不要用/——首页可能有业务逻辑耗时，导致 probe 失败误杀 Pod
非 root 用户运行不是“锦上添花”，而是准入前提
多数企业 Kubernetes 集群启用了 PodSecurityPolicy 或 PodSecurity Admission，默认禁止 root 权限容器。你本地 docker run 成功，推到集群却卡在 Pending 状态，kubectl describe pod 里能看到 container has runAsNonRoot and image will run as root。
- Alpine 镜像里加一句：
RUN addgroup -g 61 -g nonroot && adduser -S nonroot -u 61 - distroless 镜像需提前创建用户并设 UID，然后在 YAML 里写：
securityContext: {runAsUser: 61, runAsGroup: 61} - Go 进程启动前别调
syscall.Setuid之类——它需要 root 权限，跟非 root 容器冲突
真正卡住上线的，往往不是 Deployment 写错字段，而是镜像里少了个 ca-certificates 导致 HTTPS 请求失败，或是没设 resources.limits 触发节点驱逐——这些细节不会报明确错误，只会让服务间歇性不可用。
