必须显式设置CGO_ENABLED=0和GOOS=linux，否则默认启用CGO并链接libc，导致二进制在scratch或alpine中因动态链接失败而报“no such file or directory”；二者须写入go build命令而非仅ENV，且需搭配-ldflags '-s -w'精简体积。
CGO_ENABLED=0 和 GOOS=linux 必须显式写在 go build 命令里
不设这两个变量，go build 默认会启用 CGO 并链接系统 libc，导致生成的二进制在 scratch 或 alpine 上直接报错：standard_init_linux.go:228: exec user process caused: no such file or directory。这不是路径问题，是动态链接失败。
-
CGO_ENABLED=0强制走 Go 自带的纯 Go DNS、文件、网络实现，避免依赖 libc -
GOOS=linux防止你在 macOS 或 Windows 上构建出不可运行的二进制 - 必须写成
RUN CGO_ENABLED=0 GOOS=linux go build -o main ./cmd/api—— 放在ENV里无效，因为go build是子 shell 执行的 - 加
-ldflags '-s -w'可剥离调试符号和 DWARF 信息，减小 1–3MB
选 scratch 还是 alpine？看你的服务是否碰系统设施
scratch 确实最小（0MB），但它真的什么都没有：没 /etc/hosts、没证书、没时区数据。不是“能跑 hello world”就算可用。
- 只监听 HTTP、不发外网请求、不调
net.LookupHost、不用time.LoadLocation→ 可用scratch，镜像压到 4–6MB - 要调微信支付回调、短信网关、任何 HTTPS 第三方 API → 必须装
ca-certificates，选alpine:3.20+RUN apk --no-cache add ca-certificates - 要用
os/user、user.Current()、或依赖/etc/passwd→ 别碰scratch，alpine更稳妥 - 别用
alpine:latest—— 它会漂移，Go 1.21 推荐alpine:3.19，Go 1.22+ 推荐alpine:3.20
COPY --from 的路径是相对于前一阶段根目录，不是 WORKDIR
多阶段构建中，COPY --from=builder /app/main . 这行如果失败，大概率不是语法错，而是路径对不上。Docker 不继承前一阶段的 WORKDIR，/app/main 必须是 builder 阶段里真实存在的绝对路径。
- builder 阶段设了
WORKDIR /app，又RUN go build -o main .→ 二进制在/app/main - 所以
COPY --from=builder /app/main .正确；写成COPY --from=builder ./main .就会失败 - 更安全的做法：builder 阶段用
RUN CGO_ENABLED=0 GOOS=linux go build -o /tmp/main ./cmd/api，然后COPY --from=builder /tmp/main .，避免 WORKDIR 变动影响
UPX 压缩二进制要谨慎，不是所有场景都适用
UPX 能把 Go 二进制再压掉 30–50%，但代价是启动时解压耗时增加（通常 10–50ms），且某些安全策略会拒绝加载 UPX 压缩过的二进制。
立即学习“go语言免费学习笔记（深入）”；
- Serverless 场景（冷启动敏感）慎用，可能突破 500ms 限制
- CI/CD 流水线中需额外安装
upx，builder 镜像体积变大 - 部分云厂商（如 AWS Lambda 容器模式）明确不支持 UPX，会报
exec format error - 若决定用，务必加
--no-safemode参数（Go 二进制默认需要该 flag 才能 UPX）
CGO_ENABLED 漏设、scratch 误用、路径写错、UPX 乱加——镜像从 1.2GB 掉到 5MB，差的就是这四步里的某一个细节。 
