go微服务docker部署关键在镜像瘦身、进程管理、端口暴露和健康就绪探针：需静态编译（cgo_enabled=0 goos=linux）、用alpine或scratch镜像、监听0.0.0.0、配置readiness/liveness探针并优雅处理sigterm。
docker build 能跑通，不等于生产可用——Go微服务的 Docker 部署关键在镜像瘦身、进程管理、端口暴露和健康就绪探针这四件事。
Go 二进制必须静态编译，否则 Alpine 镜像会报 no such file or directory
Alpine 镜像默认不含 glibc，而 Go 默认动态链接。一旦没关 CGO_ENABLED，运行时就会卡在找不到 libc.so。
- 构建阶段务必加
CGO_ENABLED=0 GOOS=linux go build -o server . - 不要用
golang:latest做最终镜像，哪怕只 copy 二进制过去——它自带完整 Go 环境，体积暴涨且有安全隐患 - 推荐最终镜像用
scratch或alpine:latest：前者极致轻量（几 MB），后者带sh方便调试（但需手动apk add ca-certificates）
Dockerfile 多阶段构建漏掉 go.mod 和 go.sum，会导致依赖下载失败
很多新手直接 COPY . .，结果 go mod download 因缺少 go.sum 校验失败，或因 vendor 未提交导致行为不一致。
- 必须先
COPY go.mod go.sum ./，再RUN go mod download，确保构建可复现 - 源码
COPY放在go mod download之后，避免缓存失效重下所有依赖 - 如果用了私有模块（如公司内网 Git），要在 builder 阶段配置
GOPROXY和git config，否则构建中断
容器里 Go 服务没监听 0.0.0.0:8080，docker run -p 就白搭
本地开发常写 http.ListenAndServe(":8080", nil)，这在容器里等同于只监听 127.0.0.1:8080，外部请求根本进不来。
- Go 代码中无需改监听地址——
":8080"在容器网络中默认绑定到所有接口，只要不是显式写成"127.0.0.1:8080"就没问题 - 真正要检查的是
Dockerfile里的EXPOSE 8080：它只是文档作用，不影响实际行为；关键是docker run -p 8080:8080中的宿主机端口映射是否正确 - 多个微服务共存时，别让它们都用
8080——比如用户服务用8001，订单服务用8002，否则docker-compose.yml会端口冲突
Kubernetes 下没配 livenessProbe 和 readinessProbe，滚动更新会炸锅
Go 微服务启动快，但可能依赖数据库或注册中心。K8s 默认认为容器启动即就绪，实际却还在连 DB，流量进来就 500。
-
readinessProbe必须指向一个真实健康检查端点（如/healthz），不能只靠端口通 -
livenessProbe建议用独立路径（如/livez），避免和 readiness 共用——万一服务卡死但 HTTP 仍响应，K8s 不会重启 - probe 的
initialDelaySeconds至少设为 5–10 秒，给 Go 服务留出初始化时间（尤其加载配置、建连接池）
os.Signal 捕获 SIGTERM 做优雅退出，比任何外部 kill 更可靠；而用 env_file 或 ConfigMap 注入配置，比硬编码或 ARG 更安全可控。
