Dockerfile中COPY两遍会多一层，因每次COPY、RUN、ADD均创建新镜像层；应采用多阶段构建，仅复制二进制至scratch或alpine镜像，并用-ldflags "-s -w"裁剪符号与调试信息。
Go 应用 Dockerfile 里为什么 COPY 两遍会多一层？
因为每次 COPY、RUN、ADD 都会创建新镜像层，哪怕只是把编译好的二进制从构建阶段 COPY 到最终镜像，也算一层。常见写法是先 go build，再 COPY ./app /app，这一步就额外加了一层。
- 正确做法：用多阶段构建，在
builder阶段编译，然后只COPY二进制到scratch或alpine基础镜像，不带源码、不带go工具链 - 别在最终镜像里留
go.mod、go.sum或GOPATH相关目录——它们不会被运行时用到，纯属冗余层 - 如果用了
CGO_ENABLED=0，就能跳过glibc依赖，直接用scratch；否则得用alpine，但要注意某些标准库（如net）在musl下行为有差异
go build -ldflags 怎么砍掉调试信息和符号表？
默认编译的 Go 二进制自带 DWARF 调试信息和符号表，体积大、启动慢（尤其在低配容器里加载解析更耗时），还可能暴露路径、函数名等敏感信息。
- 必须加
-ldflags "-s -w"：-s去符号表，-w去调试信息；两者缺一不可 - 别写成
-ldflags="-s -w"（等号后没空格）——Docker 构建时 shell 解析容易出错，老老实实用空格分隔 - 如果启用了
pprof或需要堆栈追踪，-w会削弱错误堆栈可读性，但生产环境通常宁可少点堆栈细节，也要换启动速度和体积
为什么 Alpine 镜像有时反而冷启动更慢？
不是体积小就一定快。Alpine 用 musl 替代 glibc，而 Go 默认静态链接，看似没问题，但某些场景下会触发隐式动态行为。
- 比如用了
os/user或net包（DNS 解析），Go 会在运行时尝试加载/etc/nsswitch.conf和libnss_*—— Alpine 没这些，就会 fallback 到慢路径或失败 - 解决方案：要么用
gcr.io/distroless/static（真正无依赖）+CGO_ENABLED=0，要么在 Alpine 里补apk add --no-cache ca-certificates和bind-tools（仅当真需要 DNS 调试） - 验证方法：进容器跑
strace -e trace=openat,open,stat ./app 2>&1 | head -20，看有没有反复失败的系统调用
ENTRYPOINT 和 CMD 选哪个？怎么写才不影响信号传递？
很多 Go 程序靠 os.Interrupt 或 syscall.SIGTERM 做优雅退出，但如果 Docker 启动方式不对，SIGTERM 根本收不到。
立即学习“go语言免费学习笔记（深入）”；
- 必须用
ENTRYPOINT ["./app"]+CMD []（空数组），或者直接ENTRYPOINT ["./app", "--flag"]；别用ENTRYPOINT ./app（shell 形式）——它会绕过 PID 1，导致信号无法直传 - 如果要用环境变量或参数覆盖，用
CMD ["--port=8080"]配合ENTRYPOINT ["./app"]，这样docker run -it app --port=9000才能正确拼接 - Go 程序里记得用
signal.Notify显式监听os.Interrupt和syscall.SIGTERM，别只依赖log.Fatal这类 panic 终止
go.mod 就干净了，其实 vendor/、.git、甚至 IDE 生成的 .vscode/ 都可能被 COPY 进去——检查每一层 docker history your-image 才算真正落地。 
