Go二进制不能直接放入Alpine镜像，因其默认动态链接glibc，而Alpine使用musl libc；解决方法是CGO_ENABLED=0静态编译，生成可运行于scratch或Alpine的二进制。
Go 二进制为什么不能直接扔进 alpine 镜像？
因为默认编译的 Go 程序是动态链接 libc 的（即使你没显式调用 C 代码），而 alpine 用的是 musl libc，不是 glibc。直接拷进去运行会报错：standard_init_linux.go:228: exec user process caused: no such file or directory——这其实是找不到动态链接器，不是文件真丢了。
解决办法只有一个：静态编译。但别急着加 -ldflags '-extldflags "-static"'，Go 1.19+ 默认已禁用 CGO 构建静态二进制，只要确保构建时 CGO_ENABLED=0 就行。
-
CGO_ENABLED=0 go build -o myapp .→ 生成纯静态二进制，可安全放进scratch或alpine - 如果项目用了
cgo（比如依赖net包做 DNS 解析），CGO_ENABLED=0会导致 DNS 查找退化为纯 Go 实现（不读/etc/resolv.conf，改用内置逻辑），可能连不上内网域名——这点容易被忽略 - 想保留 cgo 又要静态链接？几乎不可行；musl + cgo 组合在 Go 里支持很弱，别硬刚
Docker 多阶段构建中怎么安全传二进制？
第一阶段用 golang:1.22-alpine（或对应版本）编译，第二阶段用 scratch 或 alpine 运行，中间只拷 COPY --from=0 /app/myapp /myapp 这种绝对路径。关键点在于：别依赖工作目录，别用相对路径，别把整个 bin/ 目录拖过去。
- 第一阶段必须显式
WORKDIR /app，然后RUN CGO_ENABLED=0 go build -o myapp .，确保输出位置确定 - 第二阶段如果选
scratch，记得提前COPY --from=0 /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/，否则 HTTPS 请求会因证书缺失失败 - 如果选
alpine作运行镜像，不用手动拷证书，但得确认它装了ca-certificates（官方镜像默认有）
如何避免构建缓存失效导致重复编译？
Docker 构建缓存对 go build 很敏感：只要 go.mod 或任一源文件变，从 RUN go build 开始所有后续层全失效。这不是 Go 特有，但 Go 项目常因小改动触发整包重编。
立即学习“go语言免费学习笔记（深入）”；
- 把
go mod download单独提成一层，在COPY go.mod go.sum .后立刻执行，利用其缓存稳定性 -
COPY . .必须放在go build之前，但尽量缩小 COPY 范围（比如排除testdata/、.git/） - 别在构建阶段跑
go test——它不贡献最终镜像，却极大拖慢构建且破坏缓存
运行时权限和信号处理怎么不踩坑？
Go 程序在容器里默认以 root 运行，但生产环境要求降权；同时，Docker 发送 SIGTERM 给 PID 1 时，Go 默认会退出，但如果你启了 goroutine 或用了 http.Server.Shutdown，就得自己接信号。
- 第二阶段加
USER 65532:65532（非 root UID），并在 Dockerfile 里提前RUN addgroup -g 65532 -f appgroup && adduser -S appuser -u 65532 - 别依赖
os.Exit(0)做清理，用signal.Notify捕获os.Interrupt和syscall.SIGTERM，再调server.Shutdown - 如果用了
exec.Command启子进程，注意容器里 PID 1 的特殊性：子进程不会被 init 收养，得自己设cmd.SysProcAttr = &syscall.SysProcAttr{Setpgid: true}防僵死
最麻烦的其实是日志和标准错误混在一起后，Docker logs 看不到结构化输出；别忘了加 log.SetOutput(os.Stderr)，不然默认写到 stdout，和业务日志搅一块儿，排查时很难分清哪条是 panic 哪条是 info。
