Go项目构建慢主因是构建流程错配：CGO_ENABLED设错、vendor处理不当、GOOS/GOARCH硬编码失当、缓存未复用；需按纯Go/CGO/混合场景精准配置，禁用-a/-i、优化GOPROXY/GOSUMDB、按需触发generate、多阶段Docker合理选镜像。
Go 项目构建慢，八成不是代码问题，而是构建方式没对齐真实需求。禁用 CGO_ENABLED、跳过测试、忽略 vendor、硬编码 GOOS/GOARCH —— 这些操作单独看都合理，但组合错位就会导致本地能跑、CI 失败、镜像启动 panic。关键得先分清：你构建的是纯 Go 二进制，还是依赖 C 库（如 Oracle、SQLite、OpenSSL）的 CGO 项目。
CGO_ENABLED=0 不是万能开关，用错会直接崩溃
很多教程一上来就写 CGO_ENABLED=0，前提是你的项目真不碰 C。一旦用了 net 包（DNS 解析）、os/user、os/signal，或第三方库含 cgo（比如 github.com/mattn/go-sqlite3），禁用后编译能过，运行时却可能卡在 getaddrinfo 或直接 panic。
- 纯 Go 场景（HTTP server、JSON API、无数据库驱动）：放心设
CGO_ENABLED=0，生成完全静态二进制，体积小、移植强 - CGO 场景（Oracle/PostgreSQL/SQLite 驱动、libgit2、ffmpeg 绑定）：必须设
CGO_ENABLED=1，且构建阶段镜像要带gcc、musl-dev等工具链 - 混合场景（主逻辑纯 Go，但某模块需调 C）：不能全局关 CGO，得用
// #cgo指令局部控制，或拆包隔离
多阶段构建里，build 阶段镜像选 alpine 还是 debian？
选 alpine 最常见，但它默认用 musl libc，而多数 CGO 库（尤其企业级驱动）只适配 glibc。直接在 golang:alpine 里 build Oracle 客户端，十有八九报 undefined reference to 'OCIInitialize'。
- 纯 Go 项目：用
golang:alpine+CGO_ENABLED=0，安全高效 - CGO 项目：优先用
golang:bookworm-slim（Debian 衍生，带完整 glibc）或官方推荐的golang:1.23-bookworm - 想省体积又必须用 glibc？可考虑
gcr.io/distroless/static-debian12作运行镜像，但构建仍需完整 base
go build -ldflags="-s -w" 之后，pprof 还能用吗？
能，但受限。-s 去符号表，-w 去 DWARF 调试信息，pprof 的火焰图仍可显示函数名和调用栈（Go 运行时自带 symbol table），但无法做源码行号映射、无法用 delve 调试、无法查看内联展开细节。
立即学习“go语言免费学习笔记（深入）”；
- CI/生产发布包：加
-s -w没问题，减小体积、加快加载 - 预发/灰度环境：建议保留调试信息，出问题时能快速定位到具体行
- PGO 优化构建：必须禁用
-s -w，否则 profile 数据无法关联到源码位置
构建提速的关键不在“删”，而在“缓”
真正拖慢构建的，往往不是 go build 本身，而是重复下载 module、反复解压 vendor、每次重编整个 cmd/。Docker 构建中，go mod download 和 go build 的 cache 命中率决定成败。
- 用
--mount=type=cache,target=/go/pkg/mod固定 module 缓存路径，避免每次清空 -
go.mod和go.sum必须在go mod download前 COPY，否则 cache 不生效 - 不要
COPY . .后再go mod download，这会让所有后续 layer 失效 - 若用 Makefile 或 CI 脚本构建，把
go build放在最后，且只 COPY 编译产物，而非整个 src
最常被忽略的一点：CGO 项目构建时，CGO_CFLAGS 和 CGO_LDFLAGS 的值必须与目标运行环境一致。比如在 Debian 构建、却部署到 Alpine，或本地 gcc 版本高于容器内版本，都可能导致运行时 segfault —— 这类问题不会在构建时报错，只在容器启动那一刻静默失败。
