单阶段Dockerfile不够轻，因其将golang:alpine开发镜像（370MB+）全部打入最终镜像，包含编译器、源码、pkg及完整Alpine运行时；而真正轻量需多阶段构建+静态编译+剥离调试信息，仅保留二进制文件，体积可压至10–20MB。
直接用 golang:alpine 做基础镜像打包，最终镜像体积会接近 400MB 以上，不是真正意义上的“轻量级”。要压到 10–20MB，必须用多阶段构建 + 静态编译 + 剥离调试信息。
为什么单阶段 Dockerfile 不够轻？
常见写法如 FROM golang:alpine 然后 go build，问题在于：镜像里既保留了 Go 编译器、pkg、src，又打包了整个 Alpine 运行时。哪怕只跑一个 gin.Default()，实际只需要 Linux 内核 + C 库（或纯静态二进制）+ 可执行文件。
- Alpine 镜像本身约 6MB，但
golang:alpine是带 SDK 的完整开发镜像，基础层就 370MB+ -
go build默认动态链接 libc，容器里还得装musl或glibc兼容层 - 未加
-ldflags的二进制含符号表和 DWARF，白占 2–3MB
多阶段构建的正确写法
第一阶段用 golang:alpine 编译，第二阶段用 scratch 或 alpine:latest 运行——只拷二进制，不带任何编译工具链。
FROM golang:1.23-alpine AS builder WORKDIR /app COPY go.mod go.sum ./ RUN go mod download COPY . . RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -ldflags="-s -w" -o /usr/local/bin/myblog . FROM scratch COPY --from=builder /usr/local/bin/myblog /myblog EXPOSE 8080 ENTRYPOINT ["/myblog"]
-
CGO_ENABLED=0强制纯静态编译，避免运行时依赖 libc -
GOOS=linux GOARCH=amd64明确目标平台，防止本地 Mac/Windows 编译出错 -
scratch是空镜像，最终镜像≈二进制大小（通常 10–15MB），但不支持sh调试；若需日志查看或临时 exec，可换alpine:latest -
COPY --from=builder只取编译产物，其余全丢弃
-ldflags "-s -w" 的取舍要点
这个参数能减掉 20–30% 体积，但会影响排障能力，得看部署环境是否允许妥协。
-
-s：删掉符号表 →panic日志里没有文件名和行号，只剩函数名 -
-w：删掉 DWARF → 无法用delve或gdbattach 调试 - 生产环境通常不需要在线调试，建议加
-s；-w可选，但加了之后pprof的源码定位也会失效 - 如果用
upx进一步压缩，需确认目标机器 CPU 架构支持（UPX 不支持 ARM64 官方 release）
暴露端口与绑定地址容易踩的坑
镜像跑起来却访问不了？大概率是 r.Run() 绑定错了地址，或者 Docker 没暴露对端口。
- Gin 必须用
r.Run("0.0.0.0:8080")，不能写127.0.0.1:8080—— 容器内127.0.0.1只通自己，宿主机连不上 -
EXPOSE 8080只是声明，不自动映射；运行时必须加-p 8080:8080 - 若程序监听
:8080（没写 IP），Gin 默认也是0.0.0.0，但显式写出更安全 - Nginx 反向代理场景下，后端服务仍要监听
0.0.0.0，否则 proxy_pass 会连不上
真正轻量的核心不在 Dockerfile 行数多少，而在是否彻底剥离了构建时依赖。哪怕一行 COPY 多写错路径，或者漏掉 CGO_ENABLED=0，最后镜像都会悄悄胖 300MB。
