报错“exec: 'gcc': executable not found”表明cgo启用但系统缺失gcc编译器，需按平台安装：linux装build-essential或gcc+glibc-devel，macos运行xcode-select --install，windows装mingw-w64并配置path；若无需c功能，可设cgo_enabled=0快速解决，但net包dns解析等将降级。
go build 报 “exec: 'gcc': executable not found” 怎么办
这是 CGO 启用状态下最直接的信号：Go 找不到 C 编译器。它不是模块冲突，但常和模块问题一起爆发，导致误判。
关键判断点：import "C" 存在、或依赖包（如 github.com/mattn/go-sqlite3、golang.org/x/sys/unix）内部用了 C 代码，就会触发 CGO；此时 CGO_ENABLED=1（默认）但系统没装 GCC，就必然报这个错。
- Linux：装
build-essential（Ubuntu/Debian）或gcc+glibc-devel（CentOS/RHEL） - macOS：运行
xcode-select --install，再确认gcc -v可执行 - Windows：装
TDM-GCC或MinGW-w64，并把bin/加进$PATH - CI 环境（如 GitHub Actions）：必须显式安装对应编译器，不能只靠
setup-go步骤
如果确定不需要 C 功能（比如纯 HTTP server、无数据库驱动），加 CGO_ENABLED=0 是最快解法——但要注意：net 包 DNS 解析会降级为纯 Go 实现（可能连不上某些内网 DNS）、os/user 在部分系统上返回空用户信息。
交叉编译时出现 “stdlib.h: No such file or directory”
这不是头文件真丢了，而是你启用了 CGO_ENABLED=1，却没告诉 GCC 去哪找目标平台的头文件。
典型场景：从 x86_64 Linux 构建 ARM64 二进制，但 GCC 还在宿主机的 /usr/include 下找 stdlib.h，而目标平台用的是另一套 sysroot。
- 必须同时设置
CGO_CFLAGS和CGO_LDFLAGS，且都包含--sysroot=/path/to/target/sysroot - 不要混用
-I/path/include和--sysroot：前者容易冲突，后者会自动包含$SYSROOT/usr/include - 验证是否生效：用
go build -x 2>&1 | grep gcc，看到命令行里出现--sysroot=...才算对 - ARM 工具链示例：
export CC=armv7l-timesys-linux-gnueabi-gcc，再配CGO_CFLAGS="--sysroot=/opt/arm-toolchain"
漏掉 --sysroot 在 LDFLAGS 中，会导致链接阶段找不到 crt1.o；漏在 CFLAGS 中，则编译阶段就卡住——二者缺一不可。
go mod tidy 后仍提示版本冲突或 missing package
go mod tidy 不会自动解决间接依赖的版本分歧，尤其当两个上游包分别要求同一模块的不同主版本时（如 v1.8 vs v1.10），Go 会保留两者并报错。
先定位源头：go mod graph | grep module-name 查谁引入了哪个版本；再用 go mod why -m github.com/sirupsen/logrus 看调用链。
- 强制统一版本：在
go.mod中加replace github.com/sirupsen/logrus => github.com/sirupsen/logrus v1.10.0，再go get github.com/sirupsen/logrus@v1.10.0 - 避免 replace 循环：比如 A replace B，B 又 replace A，会导致解析失败
-
go list -m all | grep -v '^\(github\|golang\)' | sort可快速筛出非标准库的第三方模块及其版本 - vendor 后构建失败？先
go mod verify，再检查vendor/modules.txt是否含预期版本号
replace 只作用于当前 module，不会透传给下游——如果你发的是 SDK，得让使用者自己处理版本对齐。
CI 构建成功但生产环境 panic：cgo 依赖加载失败
常见于动态链接库缺失，比如 libsqlite3.so 或 libssl.so.1.1 在目标机器上不存在，或版本不匹配。
根本原因：CGO_ENABLED=1 默认生成动态链接二进制，依赖目标机上的共享库；而 CI 环境（如 Ubuntu 22.04）和生产机（如 Alpine 3.18）的 libc 和库路径完全不同。
- 方案一（推荐）：静态链接——加
-ldflags '-extldflags "-static"'，前提是构建机装了glibc-static（glibc 系统）或musl-dev（Alpine） - 方案二：关 CGO——
CGO_ENABLED=0，但需确认所有功能（如 DNS、用户信息、加密）是否可接受降级行为 - 方案三：打包时带 so 文件——用
ldd ./binary查依赖，手动拷贝对应版本 so 到目标机/usr/lib，风险高、难维护 - docker 构建时，务必用和生产环境一致的基础镜像（如
alpine:3.18），而非golang:1.22宿主机镜像
最容易被忽略的是：本地开发时 CGO_ENABLED=1 能跑通，CI 脚本却忘了设 CGO_ENABLED=1 或没装交叉工具链，结果静默降级为 CGO_ENABLED=0，上线后才发现 DNS 解析失败——这种“降级无声”比报错更难排查。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
