必须关闭 CURLOPT_SSL_VERIFYPEER是错误认知，实际应通过Go的TLS配置加载可信CA；CGO_ENABLED=0使net等包回退纯Go实现；COPY失败多因阶段名或路径不匹配；scratch镜像需确保二进制静态链接且不依赖外部命令。
为什么必须用 CURLOPT_SSL_VERIFYPEER 关闭证书验证？
不是“必须关闭”，而是很多开发者误以为关掉它就能解决 HTTPS 请求失败——实际这是危险的权宜之计。Go 本身不依赖 cURL，但如果你在 Go 中调用 C 库或混用 PHP 风格的 HTTP 客户端（比如通过 cgo 封装 libcurl），才可能碰到这个选项。纯 Go 的 http.Client 根本没有 CURLOPT_SSL_VERIFYPEER 这个概念。
真正该关注的是 Go 自身的 TLS 配置：
- 默认情况下，
http.DefaultClient已启用证书校验，出错时会报x509: certificate signed by unknown authority - 若服务端用自签名证书，应通过
http.Transport.TLSClientConfig.RootCAs加载可信 CA，而非全局禁用验证 - 禁用验证的写法（仅限调试）：
tlsConfig := &tls.Config{InsecureSkipVerify: true}，但上线前必须删掉
Go 编译时 CGO_ENABLED=0 到底影响什么？
它决定 Go 是否链接 C 标准库（glibc/musl）。设为 0 后，net 包会回退到纯 Go 实现（如 DNS 查询走 net/dnsclient），不再调用系统 getaddrinfo；os/user、os/signal 等也受限。
常见后果：
立即学习“go语言免费学习笔记（深入）”；
- Alpine 镜像里不加
CGO_ENABLED=0，编译出的二进制仍依赖 glibc，运行时报no such file or directory - 开启 CGO 后，
time.Now()可能因 musl 的clock_gettime实现差异出现纳秒级抖动（尤其在容器中） - 某些包（如
github.com/mattn/go-sqlite3）强制依赖 CGO，此时必须保留CGO_ENABLED=1并安装对应 C 工具链
COPY --from=builder 复制失败的三个典型原因
多阶段构建中，COPY --from=builder 报 failed to compute cache key 或 no source files were specified，通常不是语法错，而是路径/阶段名不匹配。
排查要点：
- 确保
FROM golang:1.23 AS builder中的builder和--from=builder完全一致（区分大小写） - 检查第一阶段是否真生成了目标文件：编译命令必须是
go build -o /app/main .，而不能是go build -o main .（后者输出在当前目录，即/app，但若WORKDIR设错就可能找不到） - Alpine 运行阶段没装
ca-certificates，导致程序发起 HTTPS 请求时 panic，看起来像复制成功但启动失败——加一句RUN apk --no-cache add ca-certificates再试
从 alpine:latest 换成 scratch 前要确认什么？
scratch 是空镜像，连 /bin/sh 都没有，所以 CMD ["./main"] 能跑，但 ENTRYPOINT ["/bin/sh", "-c"] 必然失败。它只适合纯静态链接的 Go 二进制。
换之前务必验证：
- 用
ldd ./main检查输出是否为not a dynamic executable（说明无动态依赖） - 如果代码用了
os/exec并调用外部命令（如sh,curl），scratch里根本不存在这些程序，得改用 Go 原生实现或放弃scratch -
scratch镜像无法docker exec -it进去调试，日志只能靠stdout输出，建议至少保留一个alpine的 debug 版本用于问题定位
最常被忽略的一点：多阶段构建里，第一阶段的 go mod download 和第二阶段的 apk add 都依赖网络，CI 环境若没配代理或私有 registry，会静默卡住——别只盯着 COPY 报错，先看构建日志里有没有 Get \"https://proxy.golang.org/...\" 类超时信息。
