Go二进制不能直接用FROM golang:alpine做生产镜像，因其含编译器、shell等冗余内容，体积大且攻击面广；必须用多阶段构建分离编译与运行，优先选scratch（静态链接），否则用alpine并设CGO_ENABLED=0。
Go 二进制为什么不能直接用 FROM golang:alpine 做生产镜像？
因为 golang:alpine 是开发镜像，含编译器、go 命令、/usr/src 等冗余内容，镜像体积大（~300MB+），且带 shell 和包管理器，存在攻击面。生产环境应分离构建与运行阶段。
- 必须用多阶段构建：第一阶段用
golang:1.22-alpine编译，第二阶段用alpine:latest或scratch运行 - 若服务不依赖 libc（静态链接），优先选
scratch；若用了 cgo 或某些库（如 DNS 解析），alpine更稳妥 - 用
CGO_ENABLED=0强制静态链接，避免运行时缺失libc报错：standard_init_linux.go:228: exec user process caused: no such file or directory
如何写最小可用的 Go 多阶段 Dockerfile？
核心是两段：编译阶段复制源码 → 构建二进制 → 运行阶段仅拷贝二进制和必要配置。
- 工作目录统一用
/app，避免路径歧义 - 编译命令加
-ldflags="-s -w"去除调试信息，减小体积 - 运行阶段用
USER 65532:65532降权，别用root - 暴露端口用
EXPOSE 8080（只是声明，不影响实际监听）
FROM golang:1.22-alpine AS builder WORKDIR /app COPY go.mod go.sum ./ RUN go mod download COPY . . RUN CGO_ENABLED=0 GOOS=linux go build -a -ldflags='-s -w' -o /app/server . FROM alpine:latest RUN apk --no-cache add ca-certificates WORKDIR /root/ COPY --from=builder /app/server . USER 65532:65532 EXPOSE 8080 CMD ["./server"]
go build 的 GOOS 和 CGO_ENABLED 怎么选？
目标平台和是否启用 cgo 决定二进制能否在基础镜像中运行。选错会直接启动失败。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
GOOS=linux必须显式指定，即使你在 Linux 上构建 —— Docker 构建上下文不继承宿主机GOOS -
CGO_ENABLED=0是默认安全选项；设为1时，二进制会动态链接libc，必须用alpine或debian镜像，且alpine用的是musl，不是glibc，容易报not found - 若必须用 cgo（比如调了
net.LookupIP在某些 DNS 配置下），改用debian:slim作运行镜像，并保持CGO_ENABLED=1
为什么 docker run 启动后立刻退出？常见排查点
不是代码逻辑问题，大概率是 Dockerfile 或运行时配置导致进程无法常驻。
立即学习“go语言免费学习笔记（深入）”；
- 检查
CMD是否执行完就退出：Go 服务没加http.ListenAndServe阻塞，或监听地址写成localhost:8080（容器内 localhost ≠ 宿主机）→ 改成:8080 - 确认二进制有可执行权限：
RUN chmod +x /app/server（尤其从 Windows 拷贝来的文件可能丢掉 x 权限） - 日志没输出？加
log.SetOutput(os.Stdout)，避免被默认重定向到文件导致看不到错误 - 用
docker run -it <image> sh进去手动执行二进制，看真实报错，比如standard_init_linux.go:228: exec user process caused: no such file or directory就是 cgo 链接问题
CGO_ENABLED、GOOS、基础镜像选择、监听地址这四点只要错一个，容器就起不来 —— 而且错误信息往往不直接告诉你哪错了。 
