CGO_ENABLED=0必须设置，否则Go二进制会动态链接glibc，而Alpine使用musl libc导致“no such file or directory”错误；-ldflags="-s -w"用于剥离符号表和调试信息，通常减小30%–50%体积。
CGO_ENABLED=0 必须加，否则 Alpine 镜像运行时大概率报 no such file or directory ——这不是找不到你的二进制，而是它动态链接了宿主机的 glibc，而 Alpine 用的是 musl。
为什么 go build 在 Alpine 上跑不起来？
典型错误是：standard_init_linux.go:228: exec user process caused: no such file or directory。这个错误和路径无关，是动态链接失败。
- 默认
go build在 CGO 开启下会链接系统 libc（glibc），但 Alpine 的libc是 musl，不兼容 -
file ./myapp输出含dynamically linked就说明没静态编译成功 - 加
CGO_ENABLED=0强制禁用 cgo，才能生成真正静态链接的二进制 - 如果项目必须用 cgo（比如某些 DNS 解析、sqlite 驱动），就别硬塞 Alpine，改用
debian:slim或gcr.io/distroless/static-debian12
多阶段构建里 COPY go.mod 和 go.sum 为什么不能省？
这是为了利用 Docker 构建缓存加速依赖下载，避免每次改代码都重拉一遍模块。
- Docker 按层缓存，
COPY . .只要源码变，后续所有 RUN 都失效；但COPY go.mod go.sum ./放前面，只要没改依赖文件，go mod download这层就能复用 - 漏掉
go.sum可能导致构建结果不一致，尤其在 CI 环境中 - 别写成
COPY *.mod *.sum ./——通配符在不同 shell 下行为不一，老老实实列全名更稳
用 scratch 还是 alpine 作最终镜像？
选 scratch 更小更干净，但代价是你要自己处理证书和调试能力；alpine 折中，带 apk 和基础工具，适合需要 curl 做健康检查或临时排障的场景。
- 用
scratch：必须显式COPY --from=builder /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/，否则 HTTPS 请求失败 - 用
alpine：加RUN apk --no-cache add ca-certificates，体积约 5–6MB，比scratch大但省心 - 别用
FROM golang:xxx直接当运行镜像——那镜像含 Go 工具链、git、编译器，体积超 900MB，纯属浪费
build 时加 -ldflags="-s -w" 是干啥的？
这两个 flag 是减小二进制体积、去掉调试信息的关键，对容器镜像大小影响显著（通常压掉 30%–50%）。
立即学习“go语言免费学习笔记（深入）”；
-
-s：strip symbol table 和 debug info -
-w：skip DWARF symbol table（Go 的调试符号） - 不加的话，
ls -lh ./myapp可能显示 15MB+；加完常降到 6–8MB - 注意顺序：
go build -ldflags="-s -w" -o myapp .，引号不能漏，空格也不能错
CGO_ENABLED=0 和 -ldflags="-s -w" 这两个参数看似小，但漏一个，轻则镜像臃肿，重则容器启动即崩——它们不是“可选优化”，而是 Go 容器化部署的硬性前提。 
