根本原因是Go默认启用cgo依赖系统动态库（如libc），在Alpine或最小化Linux环境因缺少glibc或DNS解析库导致运行时报错；应设CGO_ENABLED=0静态编译，并用file命令验证是否含“statically linked”。
Go 微服务打包时为什么 go build 生成的二进制在服务器上直接运行报错？
根本原因通常是静态链接没开，导致运行时找不到 libc 或 DNS 解析失败（尤其 Alpine 镜像或最小化 Linux 环境）。Go 默认用 cgo，而 cgo 依赖系统动态库。
- 加
-ldflags '-s -w'去符号和调试信息，减小体积 - 强制关闭 cgo：
CGO_ENABLED=0 go build -a -ldflags '-s -w' -o service ./cmd/service - 若必须用 cgo（比如调用 OpenSSL），则需在目标环境装对应 dev 包，或改用
glibc基础镜像（如debian:slim），而非alpine - 验证是否静态链接成功：
file service输出含statically linked即可
用 Docker 部署 Go 微服务，Dockerfile 怎么写才不踩内存和启动失败的坑？
常见错误是直接 FROM golang:1.22 构建再运行，结果镜像几百 MB、启动慢、还带多余工具链。更关键的是，没设好 GOMAXPROCS 和信号转发，导致容器内 CPU 利用率异常或无法优雅退出。
- 用多阶段构建：
FROM golang:1.22-alpine AS builder编译，再FROM alpine:latest拷二进制 - 务必加
USER nonroot:nonroot（提前创建非 root 用户），避免安全扫描告警 - 入口加
ENTRYPOINT ["./service"]，不要用shell form（如ENTRYPOINT ./service），否则 SIGTERM 不会传给主进程 - 在
main()中监听os.Interrupt和syscall.SIGTERM，并调用http.Shutdown()—— 否则 k8spreStop超时后强杀
服务注册与发现选 Consul 还是 etcd？本地开发和生产环境怎么平滑切换？
Consul 提供 DNS 接口和健康检查 UI，但 agent 占资源；etcd 更轻量、Raft 实现更成熟，但原生无服务发现语义。实际选型不取决于功能多寡，而看团队已有基础设施和运维习惯。
- 用配置文件或环境变量驱动注册逻辑：
SERVICE_REGISTRY=consul或SERVICE_REGISTRY=etcd - 本地开发建议关掉注册（设
DISABLE_REGISTRY=true），避免每次启停都往中心写状态 - Consul 客户端初始化时必须设
http.DefaultClient.Timeout = 3 * time.Second，否则网络抖动时阻塞整个服务启动 - etcd v3 client 要显式调用
cli.Close()，否则连接泄漏 —— Go 微服务常因这个跑几天后 fd 耗尽
Kubernetes 中 Go 微服务 Pod 经常 CrashLoopBackOff，怎么快速定位？
不是日志里“connection refused”就去查下游，先看 kubectl describe pod 的 Events 和容器状态，90% 是 readiness/liveness probe 配置不当或启动太慢。
- livenessProbe 不要设
initialDelaySeconds: 5就完事 —— Go 服务冷启动可能要 8~12 秒（尤其加了 JWT 密钥加载、DB 连接池预热） - readinessProbe 的
periodSeconds建议 ≥ 10，失败阈值设 2，避免短暂 GC STW 导致误判 - 加
startupProbe（K8s 1.16+）专治启动慢的服务：failureThreshold: 30，periodSeconds: 10，给足时间初始化 - 如果
kubectl logs -p显示 panic，但没堆栈 —— 检查是否用了log.SetFlags(0)或没 flush 日志缓冲区，加log.SetOutput(os.Stdout)显式重定向
Go 微服务部署最耗时间的地方，往往不在写代码，而在反复验证「那个没写进文档的超时参数」和「那个被忽略的 syscall 信号转发细节」。
