结论：Go应用Docker化必须分离构建与运行阶段，二进制瘦身需协同控制CGO_ENABLED=0、-ldflags="-s -w"、-trimpath及GOOS/GOARCH；禁用CGO确保静态链接适配Alpine（musl），否则因glibc缺失报错；-trimpath消除源码路径暴露，GOOS=linux为跨平台编译硬性前提，Docker多阶段中依赖下载须前置以利用缓存。
直接结论：脚手架环境必须分离构建与运行阶段，二进制瘦身不是“加几个flag就完事”，而是从CGO、链接器、OS/ARCH三者协同控制的结果。
CGO_ENABLED=0 不只是开关，它决定你能不能用 Alpine
Alpine 镜像默认用 musl libc，而 Go 默认启用 CGO 时会链接 glibc；一旦编译产物依赖 glibc，扔进 Alpine 就报 no such file or directory（实际是找不到 libc.so.6）。
-
CGO_ENABLED=0强制 Go 使用纯 Go 实现的 net、os、crypto 等包，避免任何 C 依赖 - 但代价是：部分需要系统调用的功能受限（如
user.LookupId在某些 musl 版本下不可用） - 若项目真依赖 cgo（比如调用 OpenSSL 或 SQLite），就得换基础镜像——改用
debian:slim或ubuntu:22.04，并保留CGO_ENABLED=1
-ldflags="-s -w" 和 -trimpath 要一起用才有效
单独加 -ldflags="-s -w" 只删符号表和调试信息，但源码路径仍保留在二进制里（比如 /home/user/project/cmd/api/main.go），这既暴露路径结构，又增加体积。
-
-s：去掉符号表（symbol table） -
-w：去掉 DWARF 调试信息 -
-trimpath：编译时抹掉所有绝对路径，统一替换为相对路径或空字符串 - 实操命令示例：
CGO_ENABLED=0 GOOS=linux go build -ldflags="-s -w" -trimpath -o bin/api ./cmd/api
GOOS=linux 是跨平台编译的硬性前提
你在 macOS 或 Windows 上开发，但目标运行环境是 Linux 容器——漏写 GOOS=linux，编译出的二进制根本跑不起来，错误通常是 exec format error。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
-
GOOS控制目标操作系统 ABI，GOARCH控制指令集（amd64/arm64） - 边缘设备部署还要加
GOARM=5（ARMv5）或GOARM=7（ARMv7），否则 runtime panic - 建议在 Makefile 或 CI 脚本中固化：
GOOS=linux GOARCH=amd64 CGO_ENABLED=0，避免本地 shell 环境污染
Docker 多阶段构建里，builder 阶段要先下载依赖再 copy 源码
很多脚手架 Dockerfile 把 COPY . . 放在 go mod download 前，导致每次构建都失效缓存——哪怕只改一行代码，go mod download 也得重跑。
- 正确顺序：先
COPY go.mod go.sum .→RUN go mod download→ 再COPY . . - 这样只要
go.mod不变，go mod download步骤就能命中 Docker layer cache - 额外提示：如果用私有模块代理（如 GOPROXY=https://goproxy.cn），记得在 builder 阶段
ENV GOPROXY
真正卡住人的地方不在命令本身，而在环境变量作用域和 Docker 构建上下文的隐式耦合——比如 CGO_ENABLED 在 shell 中设了，但在 RUN 指令里没显式声明，就会静默失效。别信“本地能跑就行”，容器里每个环节都要显式可控。
