必须禁用CGO（CGO_ENABLED=0）静态编译，否则Go默认动态链接glibc，而Alpine使用musl libc，导致“no such file or directory”错误——实为动态链接器不匹配，非路径问题。
为什么 go build 生成的二进制在 alpine 镜像里直接报 “no such file or directory”？
这不是文件路径错了，而是动态链接失败。Go 默认启用 CGO_ENABLED=1，编译出的二进制会依赖系统级 C 库（如 libc），而 alpine 用的是 musl libc，两者 ABI 不兼容。
- 最直接的解法：构建时加
CGO_ENABLED=0，强制静态链接，生成完全自包含的二进制 - 如果项目真依赖 cgo（比如调用 SQLite、OpenSSL 等），就得用
golang:alpine构建，并在运行镜像中安装对应musl兼容的库，例如apk add --no-cache sqlite-dev - 别在
scratch镜像里硬塞动态链接二进制——它连/bin/sh都没有，更别说ld-musl
多阶段构建中 COPY --from=builder 复制失败的常见原因
复制失败通常不是路径写错，而是构建阶段名或路径没对齐。Docker 不会自动帮你猜工作目录或输出位置。
- 确保构建阶段用了
AS builder（注意大小写和空格），且COPY --from=builder中的builder和它完全一致 -
COPY --from=builder /app/main .前提是RUN go build -o main .确实把二进制放到了/app/main；如果用了-o ./dist/app，那路径就得改成/app/dist/app - 别漏掉
WORKDIR /app—— 否则COPY . .可能复制到根目录，go build输出位置就不可控
alpine vs distroless：选哪个做最终运行镜像？
二者都小，但定位不同：alpine 是“够用”，distroless 是“只够运行”。
- 用
alpine：需要调试（sh、curl、ps）、证书更新（apk add ca-certificates）、时区配置（tzdata）时更方便 - 用
distroless（如gcr.io/distroless/static-debian12）：极致安全，无 shell、无包管理器、无攻击面，但排查问题得靠日志和远程 pprof，不能docker exec -it - 注意：
distroless镜像默认不带 CA 证书，HTTPS 请求会失败，必须显式COPY --from=builder /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/
go build -ldflags="-s -w" 真的值得加吗？
加，而且建议默认加。它不改变功能，只删元数据，对生产环境有实际收益。
立即学习“go语言免费学习笔记（深入）”；
-
-s去掉符号表，-w去掉 DWARF 调试信息，通常能缩减 20%~40% 二进制体积 - 体积变小 → 镜像拉取更快、磁盘占用更低、内存映射开销略降
- 代价是：无法用
delve远程调试，堆栈追踪丢失函数名（只剩地址），但生产环境本就不该依赖这些 - 如果项目需保留部分调试能力，可只加
-w，或改用-ldflags="-buildid="清除 build id 同时保留符号
.dockerignore 的配合——哪怕只多 copy 一个 node_modules 或 vendor 目录，整个 go mod download 层都会失效，每次构建都重下全部依赖。 
