绝大多数云原生部署场景下，CGO_ENABLED=0是必须的；否则二进制会动态链接libc，在Alpine/distroless镜像中因缺失动态链接器而报“no such file or directory”，且破坏静态部署优势。
Go二进制编译时必须关掉CGO_ENABLED吗
绝大多数云原生部署场景下，CGO_ENABLED=0 是必须的。它不是“可选优化”，而是避免运行时依赖和镜像膨胀的硬性前提。
开启 CGO 会导致 Go 程序动态链接 libc（如 glibc），而 Alpine 或 distroless 镜像不含这些库，容器启动直接报错：standard_init_linux.go:228: exec user process caused: no such file or directory。即便用 Debian 基础镜像，也会引入几十 MB 的运行时依赖，破坏静态部署优势。
-
CGO_ENABLED=0强制纯静态链接，生成的二进制可直接在scratch或distroless/static-debian12上运行 - 若代码中调用了
cgo（如 sqlite、某些加密库、系统调用封装），则不能设为 0，需改用glibc基础镜像并显式安装依赖 - 本地开发调试时可保留 CGO（便于使用
net/http/pprof或某些调试工具），但 CI 构建阶段必须关闭
Docker 多阶段构建里该用 alpine 还是 distroless
优先选 distroless/static-debian12（或 gcr.io/distroless/static），而不是 alpine——尤其当你的 Go 二进制已用 CGO_ENABLED=0 编译时。
alpine 虽小（~5MB），但它自带 musl libc 和 shell，存在攻击面；而 distroless/static 是真正零用户态工具的镜像，体积更小（~2MB）、无 shell、不可交互，符合最小权限原则。
立即学习“go语言免费学习笔记（深入）”；
- 用
alpine仅适合需要调试命令（如sh、curl）的临时镜像，生产环境不推荐 -
distroless镜像无法exec进去，但可通过docker run --rm -it --entrypoint /bin/sh your-image临时覆盖入口点做诊断（前提是镜像含sh—— distroless/static 不含，需换用distroless/base-debian12） - 如果服务需解析 DNS 或处理 TLS，确保 Go 版本 ≥ 1.19（内置
net.Resolver和crypto/tls不依赖系统库）
Kubernetes 中 resources.requests 设置过低会怎样
设置过低不是“省资源”，而是引发调度失败、OOMKilled 或就绪探针反复失败——最常见表现是 Pod 卡在 Pending 或频繁重启。
K8s 调度器依据 requests 分配节点，若 requests.cpu 设为 10m，但实际启动瞬间 CPU 尖峰达 300m，节点即使有空闲算力也无法满足调度条件；而 limits 过高又可能让 Pod 被 QoS 类别降为 burstable，OOM 时优先被 kill。
- Go 服务启动初期（加载配置、初始化 DB 连接池、注册服务发现）内存和 CPU 消耗明显高于稳态，建议用
stress-ng或pprof抓取启动峰值，而非只看 steady-state -
requests.memory至少设为启动后 RSS 的 1.5 倍，否则 Kubelet 可能因内存压力主动驱逐 Pod - 对
readinessProbe延迟（initialDelaySeconds）要配合resources.requests：资源紧张时启动变慢，探针超时会导致 Pod 永远无法就绪
为什么 livenessProbe 不能只检查 HTTP 端口连通性
只用 httpGet 检查 /healthz 是否返回 200，等于没做健康检查——它无法反映 Go runtime 是否卡死、goroutine 是否堆积、GC 是否停顿。
一个典型故障场景：runtime.GC() 长时间阻塞（如内存碎片严重），HTTP server 仍能响应，但业务请求全部积压在 channel 或 mutex 上，实际已不可用。此时 livenessProbe 不重启，服务持续不可用。
- 推荐组合：HTTP 接口 +
exec执行轻量 Go 健康检查逻辑（如runtime.NumGoroutine() < 1000、debug.ReadGCStats中最近 GC 时间 < 5s） - 避免在 probe 中调用外部依赖（DB、Redis），否则 probe 失败会触发重启，形成雪崩
-
livenessProbe的failureThreshold建议 ≥ 3，防止偶发 GC 尖峰误判；periodSeconds不宜低于 10s，减少 probe 自身开销
