多阶段构建必须同时设cgo_enabled=0和goos=linux，否则跨平台构建的二进制在alpine/distroless中会因缺少动态链接器报“no such file or directory”；cmd需用绝对路径，探针initialdelayseconds须差异化配置，initcontainer用于可靠依赖等待。
Go 应用容器化不是“打包完就完事”，而是 Kubernetes 部署成败的第一道关卡。镜像不瘦、启动失败、权限报错、探针误杀——这些问题全在 Dockerfile 和构建阶段埋下伏笔。
多阶段构建必须同时设 CGO_ENABLED=0 和 GOOS=linux
本地 macOS/Windows 上用 go build 默认生成的是 host 系统的可执行文件，直接 COPY 到 Alpine 或 distroless 镜像里会报 "no such file or directory"——本质是动态链接器缺失，不是文件真丢了。
-
CGO_ENABLED=0关闭 cgo，避免依赖 libc -
GOOS=linux强制目标平台为 Linux（哪怕你在 Mac 上构建） - 二者必须同时生效，建议写成一行：
RUN CGO_ENABLED=0 GOOS=linux go build -ldflags="-s -w" -o app . - 若项目强依赖 cgo（如
sqlite3），别硬关，改用gcr.io/distroless/cc-debian12镜像
FROM scratch 镜像里没有 /bin/sh，CMD 必须是绝对路径
用 scratch 构建最小镜像很干净，但代价是：它真的空无一物。此时 CMD ["./app"] 会失败，因为 ./app 是相对路径，而当前工作目录未定义。
- 必须显式声明
WORKDIR /或WORKDIR /app -
CMD改用绝对路径：CMD ["/app"]（注意不是["/app"]加引号外层） - 验证方式：
docker run --rm -it your-image ls -l /app，确认文件存在且有x权限 - 调试时临时换回
alpine:latest，加apk add strace查 syscall 失败点
Go 应用启动慢，livenessProbe 和 readinessProbe 的 initialDelaySeconds 要分开设
Go 服务常需加载配置、连 DB、初始化 gRPC client，冷启动可能耗时 10 秒以上。如果两个探针的 initialDelaySeconds 都设成 5，livenessProbe 很可能在应用还没 bind port 时就开始探测，反复 kill restart。
-
readinessProbe.initialDelaySeconds设为 3–5 秒：只要端口监听上，就允许流量进来 -
livenessProbe.initialDelaySeconds设为 20–30 秒：等应用真正完成初始化、DB 连通、健康检查逻辑就绪后再开始探测 - 两者不能一样，更不能都设得太小；否则你会看到 Pod 在
Running和CrashLoopBackOff之间反复横跳
InitContainer 不是“可选插件”，而是解决依赖等待的刚需手段
Go 应用启动前要等数据库、配置中心或证书就绪？别在主容器里写 while true 循环——这会让 readinessProbe 失效，也违反容器单一职责原则。
- Init Container 按
spec.initContainers数组顺序执行，任一失败（exit code ≠ 0），Pod 卡在Init:Error，主容器永不启动 - 调试看日志：
kubectl logs <pod-name> -c <init-container-name></init-container-name></pod-name>，别只盯kubectl get pods - 共享数据靠 Volume：
emptyDir最常用；configMap和secret卷默认只读，Init Container 写不了 - 权限要注意：Alpine 中
sh默认 root 运行，但 Go 容器常以非 root 用户（如 UID 1001）运行，Init Container 中需chown -R 1001:1001 /shared
真正卡住上线的，往往不是 Kubernetes YAML 写得对不对，而是那个被忽略的 CGO_ENABLED=0 缺失，或是 livenessProbe 在第 6 秒就发出了第一个 HTTP 请求——而你的 Go 应用还在读 config.json 的第 3 行。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
