go编译二进制在docker中体积大，主因是默认包含调试符号、反射信息和dwarf数据；用go build -ldflags="-s -w"可减小30%~50%，二者需共用才彻底清除调试段；多阶段构建应仅copy最终二进制及必要文件，优先选scratch镜像，但需规避cgo、dns、ssl、user.lookup等隐性依赖；验证须用docker save解压检查rootfs，确保无冗余文件且二进制为statically linked。
为什么 Go 编译出的二进制在 Docker 里还是很大？
因为默认编译会包含调试符号、Go 运行时反射信息和 DWARF 数据，即使你用 CGO_ENABLED=0 关掉了 cgo，镜像体积仍可能超 20MB——问题不在代码，而在编译产物本身。
- 用
go build -ldflags="-s -w"去掉符号表和调试信息，能砍掉 30%~50% 体积 -
-s删除符号表，-w省略 DWARF 调试信息；二者必须一起用才有效 - 别信“加了 -s 就够了”，单独用
-s后readelf -S your-binary仍能看到 .debug_* 段，得-w才真正清空
多阶段构建中 COPY 什么文件最安全？
只 COPY 最终运行所需的二进制文件，别碰源码、go.mod、vendor 目录或任何中间产物。基础镜像选 scratch 时，连 /etc/ssl/certs 都没有，但 Go 静态二进制通常不依赖它——除非你用了 net/http 且需要验证 HTTPS 证书（这时得换 alpine:latest 或手动 COPY 证书）。
- 第一阶段用
golang:1.22-alpine（小、快、带 git），第二阶段用scratch（最小）或alpine:latest（需 DNS/SSL 时） - COPY 必须写绝对路径：
COPY --from=builder /app/myserver /myserver，不能写./myserver - 如果程序要读取 embed.FS 或本地配置文件，记得在 builder 阶段把它们一并 COPY 到目标路径，并在最终镜像中保留对应目录结构
alpine 镜像跑 Go 二进制有哪些隐性兼容问题？
Go 默认静态链接，但若项目间接依赖 libc（比如用了某些 cgo 包、sqlite 驱动、或调用了 user.Lookup），在 scratch 里直接 panic，而在 alpine 里可能因 musl libc 行为差异导致 DNS 解析失败、时区错乱、或 os/user.Lookup 返回空用户。
- 检查是否真用了 cgo：
go list -json | grep -i cgo，或编译时加-x看命令行里有没有 gcc - 用
ldd your-binary（在 alpine 容器里执行）确认是否动态链接——输出 “not a dynamic executable” 才是纯静态 - 避免
user.Lookup和user.Current：它们在 scratch 下必然失败，在 alpine 下依赖 /etc/passwd；改用 uid/gid 数字或环境变量传入
怎么验证最终镜像真的没多余东西？
别只看 docker images 的 SIZE 列，那包含所有层缓存。要用 docker save 导出再解压，看实际 rootfs 里有什么。
立即学习“go语言免费学习笔记（深入）”；
- 运行：
docker save myapp:latest | tar -t | grep -E "^\./[^.]" | head -20，确认只有 /myserver、/etc/ssl/certs（如有）、或空目录 - 进容器执行：
ls -la /和file /myserver，后者应显示 “statically linked” - 如果看到 /bin/sh、/usr/bin/env、/lib/ld-musl-*，说明你不小心 COPY 了不该有的东西，或者 base 镜像选错了
体积优化不是堆参数，而是每一步都清楚自己在删什么、为什么能删。一个没注意的 embed.FS 或一行多余的 COPY，就能让 8MB 镜像变成 40MB。
