go应用必须静态编译才能在alpine等轻量镜像中运行，否则因cgo启用导致动态链接libc而报“no such file or directory”；须设cgo_enabled=0、goos=linux，并用scratch或distroless镜像。
Go应用必须先静态编译再打包进容器
Go二进制文件默认是静态链接的，但如果你用了 cgo（比如调用系统 DNS 或 SQLite），就可能引入动态依赖，导致 Alpine 镜像启动失败。常见报错是 standard_init_linux.go:228: exec user process caused: no such file or directory。
- 显式关闭
cgo：构建时加CGO_ENABLED=0，例如CGO_ENABLED=0 go build -o main ./cmd/api - 若必须用
cgo（如需netgo外的 DNS 解析行为），则基础镜像不能选 Alpine，改用debian:slim或distroless/static - 交叉编译时注意
GOOS=linux GOARCH=amd64（或arm64），避免本地 macOS/Windows 编译出不可运行的二进制
Deployment YAML 中 containerPort 和 readinessProbe 要对齐
很多 Go 服务监听 :8080，但忘了在 readinessProbe 里指定相同端口，结果 Pod 一直卡在 ContainerCreating 或反复重启。Kubernetes 不会自动把 containerPort 当作健康检查端口。
-
containerPort只用于文档和 Service 端口映射，不参与探针逻辑 -
readinessProbe.httpGet.port必须显式写成数字（如8080）或引用containerPort的名字（需先在ports中定义name: http，再写port: http） - Go 服务若用
os.Getenv("PORT")启动，YAML 中也要同步设环境变量：env: [{name: PORT, value: "8080"}]，否则探针连错端口
用 client-go 连集群时，InClusterConfig 失败的三个常见原因
rest.InClusterConfig() 在 Pod 内运行时失败，不是代码问题，而是权限或环境缺失。错误通常是 open /var/run/secrets/kubernetes.io/serviceaccount/token: no such file or directory 或 certificate signed by unknown authority。
- ServiceAccount 没绑定 RoleBinding：确认 Deployment 的
serviceAccountName存在，且该 SA 已通过RoleBinding获取对应命名空间的权限 - Pod 没挂载 serviceaccount token：检查 Pod spec 中是否意外设置了
automountServiceAccountToken: false - 集群启用了 TokenRequest API 但 client-go 版本太老：v0.22+ 才完整支持，旧版（如 v0.18）会 fallback 到文件路径，而新集群可能不生成文件
ConfigMap 更新后 Go 应用不生效？别指望热重载
Go 是编译型语言，ConfigMap 挂载为文件或环境变量后，应用启动时只读取一次。修改 ConfigMap 不会触发进程重启，也不会自动 reload 配置 —— 这不是 bug，是设计如此。
- 挂载为文件时，可用
fsnotify库监听文件变更，自行实现 reload（但要注意并发安全和配置校验） - 更稳妥的做法是配合
Deployment的滚动更新：修改 ConfigMap 后，给 Deployment 加个无关 annotation（如reloader.stakater.com/last-updated: 2026-10-01T07:37），触发重建 Pod - 环境变量方式无法被 runtime 检测到变更，除非用 Downward API + initContainer 预生成配置文件再启动主进程
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
