go微服务必须用多阶段dockerfile，因为单阶段会打包完整go编译环境（约900mb），导致镜像超1gb，浪费存储、拖慢ci/cd和k8s调度；多阶段通过分离构建与运行环境，仅保留静态二进制、ca证书及必要配置，可将镜像压至10mb以内，并需严格设置cgo_enabled=0、goos=linux、显式as别名及合理基础镜像选型。
Go微服务为什么必须用多阶段Dockerfile
因为单阶段镜像会把整个Go编译环境打包进去，最终镜像动辄1GB+，既浪费存储又拖慢拉取和启动。多阶段构建能只保留运行时需要的二进制文件，把镜像压到10MB以内。
关键不是“能不能跑”，而是“跑得稳不稳、扩得快不快、查得清不清”。生产环境里，一个镜像大小翻10倍，CI流水线耗时就可能翻倍，K8s Pod调度延迟也会明显上升。
-
FROM golang:1.21-alpine AS builder这行必须带AS builder别名，否则后续COPY --from=builder会报错 - 构建阶段要先
COPY go.mod go.sum再go mod download，避免因源码变更导致缓存失效 - 运行阶段别用
alpine就完事——如果代码里用了cgo（比如调用系统DNS或SQLite），就得保留libc，此时scratch镜像会直接 panic：“exec format error” 或 “no such file or directory”
CGO_ENABLED=0 和 GOOS=linux 必须一起设
本地开发时默认 CGO_ENABLED=1，Go会链接系统glibc；但Alpine用的是musl libc，两者不兼容。不关CGO就编译，镜像一跑就崩，错误通常是 standard_init_linux.go:228: exec user process caused: no such file or directory ——其实不是文件没找到，是动态链接器对不上。
真正生效的编译命令是：
CGO_ENABLED=0 GOOS=linux go build -a -ldflags="-s -w" -o main .
-
-s -w去掉符号表和调试信息，能再减30%体积 -
GOOS=linux是必须项，即使你在Linux机器上构建，也得显式声明，否则跨平台编译行为不可控 - 如果你的服务真要依赖cgo（比如用
net.LookupIP在某些DNS配置下出问题），那就得用gcr.io/distroless/static或带musl的base镜像，不能硬切scratch
Docker Compose编排多个Go微服务时端口别写死
每个Go服务在代码里写 http.ListenAndServe(":8080", nil) 没问题，但在Compose里不能让所有服务都暴露8080——容器网络里端口是隔离的，但宿主机映射会冲突，而且不利于横向扩展。
- 代码里监听
":8080"可以，但docker-compose.yml中要用ports: ["8081:8080"]映射，让不同服务走不同宿主机端口 - 服务间调用一律用内部DNS名，比如
http://user-service:8080/user，而不是http://localhost:8081/user——后者在容器里根本不通 - 健康检查别只靠
curl -f http://localhost:8080/health，Go服务启动快，但DB连接、配置加载可能还没好，建议加个简单等待逻辑或用start_period参数
Go服务容器化后日志和信号处理容易被忽略
本地跑 ./main 时 Ctrl+C 能正常退出，但放进容器后，SIGTERM 默认被Docker转发给PID 1进程——如果Go程序没显式监听，就会被强制杀掉，连接不优雅关闭，Prometheus指标断更，K8s readiness探针失败。
- 务必在Go主函数里加信号监听：
signal.Notify(sigChan, syscall.SIGTERM, syscall.SIGINT) - 日志别只打到
fmt.Println，用log.SetOutput(os.Stdout)统一输出到stdout，Docker才能捕获并归集 - 不要在容器里后台起supervisord或tini来“保活”——Go本身已足够健壮，加一层反而增加故障点；真要进程管理，交给K8s livenessProbe就行
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
