go编译云原生应用需禁用CGO、静态链接、指定linux目标平台、使用ENTRYPOINT直接运行二进制；K8s中须监听0.0.0.0、捕获SIGTERM实现优雅退出、通过环境变量或ConfigMap读配置、镜像打唯一标签支持蓝绿/金丝雀。
Go 本身不直接“部署云原生应用”，它只负责编译出静态二进制文件；真正完成部署的是容器运行时、kubernetes 或 serverless 平台。关键在于：如何让 go build 输出的可执行文件，被云原生基础设施正确识别、拉起、扩缩、健康检查。
怎么编译出适合容器运行的 Go 二进制
默认 go build 会链接 CGO（例如调用系统 DNS 解析），导致镜像内需带 libc，体积大且存在安全风险。云原生环境要求最小化、无依赖、确定性启动。
- 始终使用
CGO_ENABLED=0 go build -a -ldflags '-s -w'：禁用 CGO、强制重新编译所有依赖、剥离调试符号和 DWARF 信息 - 显式指定目标平台，避免本地构建污染：
GOOS=linux GOARCH=amd64 go build（必要时加GOARM=7等） - 入口点必须是单个静态二进制，不要依赖
/bin/sh或其他解释器——Dockerfile 中用ENTRYPOINT ["./myapp"]，而非ENTRYPOINT ["sh", "-c", "./myapp"]
为什么 Kubernetes Pod 启动后立刻 CrashLoopBackOff
常见于 Go 应用未适配容器生命周期：进程退出即 Pod 终止，而 Go 默认不处理 SIGTERM、不等待 http server graceful shutdown、监听地址写死为 localhost:8080 导致无法被 Service 访问。
- 监听地址必须为
0.0.0.0:8080，否则容器网络栈无法接收外部请求 - 用
signal.Notify捕获os.Interrupt和syscall.SIGTERM，触发http.Server.Shutdown()，并设好超时（如 10s） - Liveness probe 不要指向可能阻塞的端点（如
/healthz返回慢），更别用exec类型去跑ps aux | grep myapp—— 容器里没ps，且违背不可变原则
如何让 Go 应用感知 Kubernetes 环境配置
硬编码配置或挂载 ConfigMap 后仍需 Go 主动读取，且要注意热更新与竞态问题。
立即学习“go语言免费学习笔记（深入）”；
- 环境变量优先级最高：
os.Getenv("DB_HOST")，K8s 中通过envFrom: [{configMapRef: {name: app-config}}]注入 - ConfigMap 文件挂载路径（如
/etc/config/app.yaml）需在 Go 启动时一次性ioutil.ReadFile加载，除非业务明确需要热重载——此时应监听fsnotify事件，且用sync.RWMutex保护配置结构体 - Service DNS 名（如
redis.default.svc.cluster.local）可直接用于net.Dial，无需额外解析库；但注意 Go 1.19+ 默认启用net.Resolver的缓存，若 DNS 变更频繁，需设置Resolver.PreferGo = true并手动控制 TTL
用什么方式发布才能支持蓝绿/金丝雀
Go 应用本身不提供发布策略，必须靠 K8s 的资源编排能力配合二进制版本管理来实现。
- 每个
go build必须打唯一标签（如 git commit SHA 或语义化版本），镜像 tag 写成myapp:v1.2.3-abc123，禁止用latest - Deployment 的
spec.template.spec.containers[].image改变后，K8s 自动滚动更新；但蓝绿需两个独立 Deployment + Service 切流，金丝雀则依赖 istio/Argo Rollouts 等控制器注入流量规则 - Go 程序内部无需写“判断当前是 v1 还是 v2”的逻辑——那是基础设施层的事；你只需保证每次构建产物是确定性的、可回滚的、带完整构建元信息（可通过
-ldflags "-X main.version=..."注入）
最常被跳过的一步：没有把 go mod vendor 或 go build -trimpath 纳入 CI 流程，导致本地能跑、CI 编译失败，或者镜像里混入开发机路径信息。云原生不是换个部署方式，而是把构建、验证、分发全链路变成不可变声明。