go云原生部署失败主因是环境配置与k8s预期不匹配：需设goproxy为国内代理、cgo_enabled=0静态编译、独立端口运行健康探针，并确保flag解析在main函数内。
Go 开发环境搭好了，但一到云原生部署就卡在编译产物不兼容、镜像启动失败、健康探针反复重启——根本不是语言问题，是环境配置和构建链路没对齐 Kubernetes 的预期。
go mod init 后 go build 报错找不到包
常见现象是 cannot find package "github.com/xxx"，尤其在公司内网或用私有模块时。这不是 GOPATH 时代的老问题，而是模块代理没生效。
- 检查
go env GOPROXY，国内必须设为https://goproxy.cn,direct或https://mirrors.aliyun.com/goproxy/,direct - 若用私有仓库（如 GitLab），需额外配置
go env GONOPROXY=git.example.com/mygroup/* -
go mod download手动触发一次依赖拉取，再go build；避免直接go run掩盖模块未加载问题
交叉编译生成的二进制在 Linux 容器里 panic: “exec format error”
这是 macOS 或 Windows 上直接 go build 出来的可执行文件，试图扔进 scratch 或 alpine 镜像运行导致的。Go 默认链接的是宿主机系统 libc，而 alpine 用的是 musl。
- 生产构建务必加
CGO_ENABLED=0：它禁用 cgo，生成纯静态链接二进制，能跑在scratch - 显式指定目标平台：
GOOS=linux GOARCH=amd64 go build -o app .（ARM64 用GOARCH=arm64） - 验证是否静态链接：
file app输出含statically linked才安全；若含dynamically linked，说明CGO_ENABLED=1或没生效
Docker 镜像里 /healthz 返回 503 或超时
Kubernetes livenessProbe 失败不是因为代码写错了，而是探针端口没暴露、HTTP server 没单独起、或没设超时——它和主服务共用一个 http.Server 实例时，中间件（如 JWT 验证、日志）会拦截探针请求。
- 必须用独立
http.Server监听另一个端口（如 8081），只挂/healthz和/readyz路由 - 用
http.TimeoutHandler包裹 handler，例如：http.ListenAndServe(":8081", http.TimeoutHandler(http.DefaultServeMux, 1*time.Second, "timeout")) - 确保
livenessProbe.httpGet.port和readinessProbe.httpGet.port在 Deployment YAML 中与监听端口一致
CI 构建时 go test 通过，但容器里 app --help 报错 “flag provided but not defined”
这是 flag 包初始化顺序问题：main 包里提前调用了 flag.Parse()，而子命令（比如用 urfave/cli 或 spf13/cobra）还没注册自己的 flag。本地开发可能碰巧不触发，CI 环境更严格。
- 不要在包级变量初始化时调用
flag.Parse()；所有 flag 解析必须放在main()函数入口之后 - 若用 cobra，确保
rootCmd.Execute()是唯一入口，别在 init() 里调flag.String()等 - 交叉编译时加
-ldflags="-s -w"可减小体积，但不会影响 flag 行为；出问题先查 flag 初始化时机
真正卡住人的从来不是语法，而是构建环境与运行环境之间那几行被忽略的 CGO_ENABLED、GOOS、GOPROXY 和探针端口隔离——这些值一旦写死在 Makefile 或 CI 脚本里，改起来比重写逻辑还费劲。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
